Hacker News Reader

Comment by Xcelerate | Hacker News Reader

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 :( )

View on HN

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.

How stable where those fixes? I.e. if you made slight changes to the C code, did the optimizations still kick in?

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.

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.

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.

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.

> 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.

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

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

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.

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.

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.

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.

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.

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 :(

Oh God. Don't get me started on const.

    const char * const fuck_this(const char *shit) const;

Thing #1: In C++ the word "const" can mean many things depending on position and inflection: declaring a symbol an actual constant; a pointer argument has in (as opposed to in-out) semantics; a function has no side effects. I keep forgetting which use of const does what.

Thing #2: Each use of const, regardless of meaning, induces a different type. Which makes API design a pain in the ass since you can't pass in stuff that wasn't declared with the same constness if the procedure expects const parameters without casting the parameters. I actually worked on a codebase where a guy broke much of our code by checking in a "fix" for our APIs to make them comply with what he considered best practice regarding constness.

Thing #3: Passed-in pointers and references are not 'const' by default. You should have to declare intent to clobber their referents.

Thing #4: And as someone said downthread, you can cast around it in most cases anyways.

This is why I say, if you're thinking of using C++, reach for Ada instead. Ada's reputation has been necessarily tainted by whiners complaining about its verbosity. But I swear that figuring out a page of Ada code is easier than figuring out a few lines of sufficiently complicated C++. For one thing, in Ada, function/procedure parameters are 'in' (i.e., const) by default, and you must declare intent to modify parameters in side effects by declaring them 'in out'.

Reply on news.ycombinator.com