> I did read the article, and to find my suggestion terrible indicates that you don't know how CPU instruction pipelines work. My suggestion will give you a big

> I did read the article, and to find my suggestion terrible indicates that you don't know how CPU instruction pipelines work. My suggestion will give you a big win because of branch prediction optimization. Without it, the CPU pipeline will be processing less instructions in parallel because the condition will be false in most cases. Thank you, Captain Obvious, for that very simplified explanation of junior undergrad systems architecture. That would all be very important if branch prediction misses were your biggest problem. Maybe look up the Sieve of Eratosthenes people keep mentioning because hey, people keep mentioning it for a reason! Arguing about branch misses in this algorithm is like arguing about branch misses in a bogosort implementation. The correct optimization isn't to remove branch misses, it's to stop using bogosort and use a reasonable sorting algorithm. I'll charitably believe that you read the article, but if you're still complaining that the code is unoptimized when the author clearly said it was unoptimized then you didn't understand the article. The article isn't about code optimization, it's about gathering performance metrics for naively-written code. It's profiling the language, not the code. > If you cannot tell me where the bottleneck is (what's saturated), then you are better off not doing anything. I'll tell you one thing for sure: the bottleneck isn't branch prediction misses. EDIT: Just to tack on more reasons you're wrong here: 1) You don't actually know that what you did removed any possible branch prediction misses without looking at the generated assembly, and 2) you could probably eliminate more branches using a switch-case statement (although again you'd have to look at the generated assembly to see if that's the case).