1

a and limit are both vectors, this is an example of their initialization

vector<int> a(10,0);
vector<int> limit(10,10);

This simple piece of code

if (a[i]+1 < limit[i]) a[i]++;
else {
}

It consumed more than 6% of process time as shown in performance profiler after compile.
Can it be optimize even more?

gsamaras
  • 71,951
  • 46
  • 188
  • 305
B. Liew
  • 37
  • 3
  • 4
    It's somewhat conceivable that `a[i] += (a[i]+1 < limit[i]);` would be faster (due to nominal lack of branch). – Oliver Charlesworth Jul 14 '16 at 21:19
  • 3
    6% is not much. Even if you got that statement to no time at all, the total speedup would be 100/94 = 1.064. In other words, a speedup of 6.4%. Hardly enough to notice. What is the program doing the other 94% of the time? – Mike Dunlavey Jul 14 '16 at 21:23
  • 1
    "6% of process time" is meaningless without some reference point. anyway, this is almost certainly premature optimisation. – underscore_d Jul 14 '16 at 21:27
  • The variant that @OliverCharlesworth suggests certainly does vectorize differently. See, e.g., https://godbolt.org/g/NA0op5. – wilx Jul 14 '16 at 21:36
  • @OliverCharlesworth Your trick seems good, but is it viable if you have an else statement afterwards? – B. Liew Jul 14 '16 at 21:44
  • @B.Liew: Probably not. That's the reality of optimisations - they're generally only useful in very specific situations. – Oliver Charlesworth Jul 14 '16 at 21:45
  • 1
    To expand: IMO, worrying about such things - unless you have absolutely, 100% exhausted the real improvements you can make to your program in terms of features, clarity, maintainability - is premature optimisation that impedes real progress. But sure, if you're already there, then great, and carry on! – underscore_d Jul 14 '16 at 21:56
  • The only other thing I'd say is to quote a previous, now deleted comment I wrote - to caution readers against, as Oliver indicated, assuming that any suggested tricks here are always going to be applicable: "I don't see how such questions help you understand the language of C++, given that they're about highly situational _maybe_ micro-optimisations in a particular dialect of machine code, architecture/stepping of CPU, and compiler - none of which are formally known to the language." And you didn't specify which of any of those you're targeting! Such questions are at risk of being "too broad". – underscore_d Jul 14 '16 at 21:58
  • 2
    I dunno... Assuming the profiler is accurate, 6% sounds pretty significant to me. Who knows, if all it takes is a stupid hack to eliminate it, that's a free 6% speedup. (Not saying that's the case here, but I *am* saying that you shouldn't overlook numbers like 6% if there's a potential for an easy fix.) – Mysticial Jul 14 '16 at 21:59
  • @underscore_d I thought there would be a simple and faster code for my question, but the piece of code I given seems to be what everyone is using. So there seems to be no potential for an easy fix other than what Oliver mentioned. – B. Liew Jul 14 '16 at 22:10
  • Is the if-else block inside a loop? – Garland Jul 14 '16 at 22:28
  • @gxy Yes. it is actually a bitwise method, increment if the last element of a whenever possible and when it reach its limit, then the else statement will reduce the i by one then increment the second last element of a. Continue until the first element of a reach its limit. – B. Liew Jul 14 '16 at 22:39
  • @Mysticial As a rule of thumb, any work that doesn't make it twice as fast is time wasted, and any work that doesn't make it ten times as fast is in practical terms uneconomic. – user207421 Jul 14 '16 at 23:24
  • 1
    @EJP That would depend heavily on what industry you're in. Where I'm at, that attitude will get you fired. – Mysticial Jul 14 '16 at 23:40
  • 1
    @Mysticial: Here's the kind of thing I've seen. The profiler could point to something that's 6% of time, and people get all intense over it. Meanwhile there's something that's 30% of time that the profiler *doesn't* point to, so it isn't seen. But with a better profiler or technique it *can* be found. Then there could be another thing of 20% the original profiler also didn't see, but it is now bigger, by a factor of 100/70, or 29%. This can keep going, until nothing more to fix is seen, but it only works if the profiler or technique is good enough. Now what was 6% is much more significant. – Mike Dunlavey Jul 15 '16 at 01:45

0 Answers0