3 ms·

Why do many Hacker news commenters criticize posts without understanding what the writer is trying to do? The purpose is to benchmark the language, not to come

Why do many Hacker news commenters criticize posts without understanding what the writer is trying to do? The purpose is to benchmark the language, not to come up with the most efficient algorithm. Further, your suggested optimization is terrible. Even if it turns out that's slightly faster (which I'm not convinced it is: did you actually compile that code and look at the generated assembly or profile it?) there are much bigger wins to be had by using a better overall algorithm, such as the sieve of Eratosthenes, which was mentioned in the article if you had read it. I know I'm being a grumpy old man here, but if you decide to comment on articles you either didn't read or didn't understand, you've only yourself to blame.

deleted 11y ago
[deleted]
halayli 11y ago
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. When you benchmark, it's important to know what you are doing or you'll arrive to the wrong conclusions because of unknowns you aren't aware of. Writing some code to generate performance numbers and jumping to conclusions without understanding what influenced the numbers is unproductive to say the least. These conclusions influence a lot of code that will be written in the future. If you cannot tell me where the bottleneck is (what's saturated), then you are better off not doing anything.
- copsarebastards 11y ago
  > 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).

deleted 11y ago

[deleted]

halayli 11y ago

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. When you benchmark, it's important to know what you are doing or you'll arrive to the wrong conclusions because of unknowns you aren't aware of. Writing some code to generate performance numbers and jumping to conclusions without understanding what influenced the numbers is unproductive to say the least. These conclusions influence a lot of code that will be written in the future. If you cannot tell me where the bottleneck is (what's saturated), then you are better off not doing anything.

copsarebastards 11y ago
> 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).