On 30/05/2011, at 11:30 PM, Oleg Krupnov wrote: > In fact, in the meantime I created a quick and dirty prototype to > measure this operation isolated, and it seems that out of 3 options > (plain if, function pointer, and pointer arithmetics) the plain if is > the winner, surprisingly :)
Not that surprising. Modern CPUs are highly pipelined, and a conditional like that won't slow things if it's repeatedly coming up with the same answer. > One thing that bothers me though. How the compiler will understand > that the state is loop-invariant? Should I necessarily declare the > checked boolean state as a local stack variable (unlike to a class > member variable that may change as a side-effect, if foo() was a class > method)? No, just leave it. It can see that it's loop-invariant because it's passed in as a value to the function - within the function nothing ever changes its value. Copying it to another variable might do more harm than good (though I suspect the optimizer wouldn't be fazed by that). Another way to "optimise" in a simple manner is just to have two loops, one for true and one for false. Effectively that's how the optimizer rewrites your code anyway. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
