5 ms·

The poor compilers do the best with what they have. And by "what they have", I mean the things they can't make assumptions about. Which turns out to be a crap

The poor compilers do the best with what they have. And by "what they have", I mean the things they can't make assumptions about. Which turns out to be a crapload. Until that happens, very highly-tuned assembly will continue to outperform the best compilers. Of course, a more typical scenario is hand-tuning a few loops where 99% of the clock cycles occur and letting the compiler take care of the rest. (Also, I was attempting to send a Morse code message by flashing the vote counter between up and down, but I don't think anyone got it :( )

timmipetit 14y ago
I saw the flashing vote counter, and was just thinking that SO was getting funky.
andremedeiros 14y ago
I will meet you at said coordinates and bring the pineapple you've requested.
andrewaylett 14y ago
I used to work on a compiler for an embedded system. One fun trick we used while writing the run-time libraries was to write them in C, then optimise the generated assembly (possibly by rewriting it from scratch), then fix the compiler so it generated that assembly :). Sometimes that did require using (and occasionally adding) new intrinsics.
- eru 14y ago
  How stable where those fixes? I.e. if you made slight changes to the C code, did the optimizations still kick in?
  - smcl 14y ago
    I worked in the same company (Hey Andrew!). It would definitely depend on the specific instructions/optimisations involved but I believe they were generally pretty robust to changes. Some would require the user to supply pragmas (i.e. to specify data alignment, etc) but obviously the compiler intrinsics would always generate the expected instructions.
keeperofdakeys 14y ago
There are some magic keywords, like const, which definitely help the compiler. Unfortunately these kinds of optimisations are far too numerous, and soon become tedious. After a certain point, more structured languages could allow much more rigid optimisation. These days JIT seems to have taken over though, which isn't really a bad thing.
- AshleysBrain 14y ago
  Const doesn't actually help compilers (at least in C/C++ based languages). Since it can be const_cast away and still work in a standards compliant way, any optimisation assuming const values never change is a bug. Instead the compiler will use other techniques, e.g. finding variables that are only written to on initialisation, and those don't even need to be marked const.
  - koenigdavidmj 14y ago
    I've seen gcc turn a const bool& into a direct pass of a bool by value. Of course, I noticed this because it was the implementation of a web service binding, and the wrapper was going to pass me a bool& (as a pointer) whether I liked it or not. Instant segfault...but not always :(
  - _kst_ 14y ago
    If an object is defined as const, casting away its constness and modifying the object causes the program's behavior to be undefined. Compilers are free to take advantage of that.
    - AshleysBrain 14y ago
      Do you have a spec reference for that? I was under the impression you could safely const_cast and modify pretty much anything. Perhaps it was just primitives like ints, or const member functions.
    - mikeash 14y ago
      That is true, but it's extremely rare to be able to take advantage of that. When people think of const as a potential optimization aid, it's almost always in the context of const pointers, which actually do nothing at all for optimization.
codeflo 14y ago
Most of all, the compiler can't change the layout of your data. Many of the use cases for hand-crafted assembly involve SIMD instructions, which perform several operations in parallel. These vector instructions can be incredibly fast, but their limitations often mean that you need to carefully design the data structures of the whole program around the optimization of one single critical loop.
- colanderman 14y ago
  I've written lots of code that either GCC has autovectorized into SIMD instructions, or that I've represented using GCC's vector types which produce SIMD instructions. While it is true that a poor choice of data structure will preclude SIMD optimizations, use of a compiler does not preclude the same.
  - pmr_ 14y ago
    At the same time I have seen autovectorization to fail on things that would look like obvious candidates or to generate still sub-optimal code. I would prefer autovectorization over hand-written SIMD code everyday but that key here is reliability. If I cannot guarantee that the performance is going to stay the same across different compiler releases (which is often that case with autovectorization) it is much more convenient to just write the optimization myself and be sure that it is going to happen regardless of the environment.
- zurn 14y ago
  > the compiler can't change the layout of your data Sure it can, this is the most promising optimization avenue currently. Not just on the micro level to make data layout more SIMD-friendly, but more cache friendly object layout etc. Modern systems are primarily memory bound, not ALU bound, so squeezing out clock cycles from computations is pretty far in the dimishing returns territory. C/C++ have forbidden these kinds of optimizations but it's a the future (tm) in high level languages.

timmipetit 14y ago

I saw the flashing vote counter, and was just thinking that SO was getting funky.

andremedeiros 14y ago

I will meet you at said coordinates and bring the pineapple you've requested.

andrewaylett 14y ago

I used to work on a compiler for an embedded system. One fun trick we used while writing the run-time libraries was to write them in C, then optimise the generated assembly (possibly by rewriting it from scratch), then fix the compiler so it generated that assembly :). Sometimes that did require using (and occasionally adding) new intrinsics.

eru 14y ago
How stable where those fixes? I.e. if you made slight changes to the C code, did the optimizations still kick in?
- smcl 14y ago
  I worked in the same company (Hey Andrew!). It would definitely depend on the specific instructions/optimisations involved but I believe they were generally pretty robust to changes. Some would require the user to supply pragmas (i.e. to specify data alignment, etc) but obviously the compiler intrinsics would always generate the expected instructions.

keeperofdakeys 14y ago

There are some magic keywords, like const, which definitely help the compiler. Unfortunately these kinds of optimisations are far too numerous, and soon become tedious. After a certain point, more structured languages could allow much more rigid optimisation. These days JIT seems to have taken over though, which isn't really a bad thing.

AshleysBrain 14y ago
Const doesn't actually help compilers (at least in C/C++ based languages). Since it can be const_cast away and still work in a standards compliant way, any optimisation assuming const values never change is a bug. Instead the compiler will use other techniques, e.g. finding variables that are only written to on initialisation, and those don't even need to be marked const.
- koenigdavidmj 14y ago
  I've seen gcc turn a const bool& into a direct pass of a bool by value. Of course, I noticed this because it was the implementation of a web service binding, and the wrapper was going to pass me a bool& (as a pointer) whether I liked it or not. Instant segfault...but not always :(
- _kst_ 14y ago
  If an object is defined as const, casting away its constness and modifying the object causes the program's behavior to be undefined. Compilers are free to take advantage of that.
  - AshleysBrain 14y ago
    Do you have a spec reference for that? I was under the impression you could safely const_cast and modify pretty much anything. Perhaps it was just primitives like ints, or const member functions.
  - mikeash 14y ago
    That is true, but it's extremely rare to be able to take advantage of that. When people think of const as a potential optimization aid, it's almost always in the context of const pointers, which actually do nothing at all for optimization.

codeflo 14y ago

Most of all, the compiler can't change the layout of your data. Many of the use cases for hand-crafted assembly involve SIMD instructions, which perform several operations in parallel. These vector instructions can be incredibly fast, but their limitations often mean that you need to carefully design the data structures of the whole program around the optimization of one single critical loop.

colanderman 14y ago
I've written lots of code that either GCC has autovectorized into SIMD instructions, or that I've represented using GCC's vector types which produce SIMD instructions. While it is true that a poor choice of data structure will preclude SIMD optimizations, use of a compiler does not preclude the same.
- pmr_ 14y ago
  At the same time I have seen autovectorization to fail on things that would look like obvious candidates or to generate still sub-optimal code. I would prefer autovectorization over hand-written SIMD code everyday but that key here is reliability. If I cannot guarantee that the performance is going to stay the same across different compiler releases (which is often that case with autovectorization) it is much more convenient to just write the optimization myself and be sure that it is going to happen regardless of the environment.
zurn 14y ago
> the compiler can't change the layout of your data Sure it can, this is the most promising optimization avenue currently. Not just on the micro level to make data layout more SIMD-friendly, but more cache friendly object layout etc. Modern systems are primarily memory bound, not ALU bound, so squeezing out clock cycles from computations is pretty far in the dimishing returns territory. C/C++ have forbidden these kinds of optimizations but it's a the future (tm) in high level languages.