Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beating the Compiler

codersnotes.com

Post reply on HN
Print view View original

11–20 of 89 posts

Re: Beating the Compiler

#11

Post by kayamon »

Joky wrote: post #5

This seems quite ridiculous to me, I have seldom seen "modern compilers are always faster than you" but rather "they are good enough that it is not worth it". It provides a very over-confident "conclusion" based on a single dubious test. The main advantage of compilers is that the optimizations scale across a large codebase through inlining for example. Also, just moving from Sandy-Bridge to Haswell for example can h…

On the contrary, I've often seen the "you can't beat the compiler" statement. This[1] recent reddit thread has it in the top comment, which is what prompted me to test it out.

And while all those other points are fine points (and I mention all that in the conclusion), it doesn't change the fact that beating the compiler isn't always the rocket science it's made out to be.

[1] https://www.reddit.com/r/programming/comments/5f9evm/learnin...

Re: Beating the Compiler

#12

Post by kayamon »

olzhas wrote: post #10

why the best-case was chosen instead of mean or median?

If the thing you're timing is expected to have a constant running time, the only thing that can slow it down is external factors (e.g. OS background tasks).

Best-case over a large number of runs is the correct way to approach the ideal running time of the task in this case, as you can eventually hit a run that didn't get impeded by anything.

Re: Beating the Compiler

#13

Post by skybrian »

olzhas wrote: post #10

why the best-case was chosen instead of mean or median?

When optimizing code, you probably want to work on performance improvements that can actually be fixed by editing the code.

Most of the things you can directly affect are things that happen in every test run, so best-case will include them.

Slower test runs will include events that don't happen on every test run (the computer is busy doing something else), so editing the code has less effect on them, and possibly none at all if it's completely unrelated.

Maybe those other events causing slowdown should be investigated too? But usually you want to look for a way to make them happen every time before working on them.

Re: Beating the Compiler

#15

Post by mistercow »

>where making good use of the SIMD intrinsics can allow assembly to massively beat the compiler.

Is this the correct use of this terminology? I thought intrinsics were functions that allow you to tell the compiler to use particular instructions, specifically so you can avoid dropping into assembly. In assembly, wouldn't you just call them "instructions"?

Re: Beating the Compiler

#16

Post by _cbsz »

I would like to see in the article a discussion of the assembly the compiler produces, how it differs from the assembly the author wrote, and perhaps why the differences are worse.

Re: Beating the Compiler

#17

Post by kayamon »

mistercow wrote: post #15

>where making good use of the SIMD intrinsics can allow assembly to massively beat the compiler. Is this the correct use of this terminology? I thought intrinsics were functions that allow you to tell the compiler to use particular instructions, specifically so you can avoid dropping into assembly. In assembly, wouldn't you just call them "instructions"?

Yeah you're right, I'll fix that.

Re: Beating the Compiler

#18

Post by _cbsz »

It's not mentioned in the article, so I'll note that the code presented is Windows-specific. Windows uses a different calling convention (https://en.wikipedia.org/wiki/X86_calling_conventions#Micros...) from the one used on Mac and Linux systems (https://en.wikipedia.org/wiki/X86_calling_conventions#System...), so if you want to see the assembly you get from clang on Mac, you'll want to annotate sortRoutine with __attribute__((ms_abi)).

Re: Beating the Compiler

#20

Post by JoshTriplett »

Joky wrote: post #5

This seems quite ridiculous to me, I have seldom seen "modern compilers are always faster than you" but rather "they are good enough that it is not worth it". It provides a very over-confident "conclusion" based on a single dubious test. The main advantage of compilers is that the optimizations scale across a large codebase through inlining for example. Also, just moving from Sandy-Bridge to Haswell for example can h…

It's less that "you can't beat the compiler", but rather that "trying to beat the compiler can backfire if you don't take a great deal of care". Some optimization advice doesn't apply to current compilers or systems, and can produce actively worse results. The worst-case scenario isn't "you did no better than the compiler", it's "you did much worse than the compiler".
Post reply on HN