Hacker News Reader

Comment by robmccoll | Hacker News Reader

I really like the conversation with the compiler approach. I had the good fortune to write some code for one of these: http://en.m.wikipedia.org/wiki/Cray_XMT which is a multi socket TB-scale shared memory machine with 128 hardware thread contexts per socket. It has an autoparallelizing C compiler that attempts to parallelize mostly for loops where it thinks it can (really quite a clever thing), but you can also tell it where to do things and give it hints through compiler pragmas. The compiler infrastructure will print out annotated copies of the code that tell you where it did and didn't parallelize and why. The effect is that you have this conversation with the compiler in which each of you tries to tell the other how to make the code more parallel (which in the case of the XMT means better and faster). It's very simple but the result can be orders of magnitude improvement.

View on HN

A couple of years back I was working as a programmer, working on an application written in C. The application was always built with all optimizations disabled, because a bug in the compiler's optimizer (is that the correct term?) had bitten the programmers, so they had become really careful.

One day, as an experiment, I built the applications with pretty much all safe optimizations enabled and did a simple benchmark that showed a performance improvement of ... (drum-roll) two percent. This left me scratching my head, wondering if that meant the compiler really sucked at optimizing the code or if the code was so badly written the optimizer could not really do anything about it (or maybe it was so well-written it already was close to optimal without "optimizing" it? Probably not.).

How nice would it be, I thought, if the compiler could give me some kind of feedback on which parts of my source code it did or did optimize, and why.

I am relieved to hear (well, read, technically speaking) that I am not the only person to have had that idea.

Many programmers have all kinds of ideads in their heads about how writing their code in a certain way will make it easier for the compiler to optimize the heck out of it, but I guess few actually go and check if their assumption have any basis in reality.

It would be so incredibly nice to have a compiler that told you about such things, so you could know if your assumptions were true or bogus.

Sigh

SGI's compilers provided this feedback back in the 90's. I have been working with domain-specific languages for years but I would have thought what was relatively common back then persisted...

In my experience (computationally-intensive numerical simulations), the optimizers helped. Although we had to use a language that was algebra (Fortran derivatives), write C-tran with #pragmas to help out the optimizer or use hand-coded libraries for things like LAPACK.

I'm guessing that the XMT compiler mentioned upthread came from Tera, rather than SGI, but it's still interesting that significant parts of SGI (maybe including those same compilers?) ended up at the same company as the XMT compilers.

Just curious, was this a CPU bound program?

Pretty much. The CPU-intensive part was computational geometry. It certainly did not help that we were four programmers, and none of us had a strong background in math. I suggested once hiring a math-kahuna just to optimize the geometry-stuff, but money was rather tight. Also, the other programmers were very conservative. Once, an intern rewrote the geometry stuff using DirectX, so stuff like overlap detection for polygons could be offloaded to the graphics hardware, but my boss refused to adopt this into our code.

Also, we used a version of OpenWatcom that was rather old-ish even back then ("back then" being ~2007-2009), which knew nothing of SSE or stuff like that. Multi-core CPUs were around, but few if any of our customers used them, so multi threading was not really an option, either.

UPDATE: As a side note, I once tried recoding a few very simple but heavily-used utility functions in assembly. That was pretty much my only contact with raw assembly. When I compared my versions to what the compiler made of the C-version, they looked nearly identical. I never knew whether to be proud or ashamed of that. Then again, the assembly version was glaringly obvious... (For comparison, I also compiled those C functions with gcc, and the output looked nearly identical to my version.)

SBCL will emit (rather verbose) annotations if you ask it to optimize.

It would be so incredibly nice to have a compiler that told you about such things

gcc can output such information for autovectorization (-ftree-vectorizer-verbose=[n])

That is good to know.

But while for some tasks this may be crucial, vectorization is only a part of the arsenal of optimizations gcc may apply.

Recently, there was discussion here on HN about C compilers (gcc, clang) exploiting undefined behaviour for optimizations that could be ... surprising. That, too, would be nice to know about.

The general idea of a dialogue between a programmer and a compiler about how (and where) to optimize a program is very intriguing.

gcc and clang can output before/after output for all their passes. Try '-fdump-ipa-all -fdump-tree-all -fdump-rtl-all-slim' on gcc, I forget the llvm options.

It's not especially readable, though.

Also, for ghc you can use '-v5' and the option that writes out C output. Prepare to be impressed(?) at how much it doesn't look like a fast C program.

I'm still a big fan of the feedback offered by the XMT's compiler. I think it's a lot more important/useful when the difference between success and failure is a few orders of magnitude (as when trying to parallelize for a target with plenty of processors).

Reply on news.ycombinator.com