4 ms·

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,

by krylon 12y ago

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

jleyank 12y ago
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.
- kragen 12y ago
  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.
nomel 12y ago
Just curious, was this a CPU bound program?
- krylon 12y ago
  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.)
  - deleted 12y ago
    [deleted]
gsg 12y ago
SBCL will emit (rather verbose) annotations if you ask it to optimize.
danieldk 12y ago
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])
- krylon 12y ago
  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.
  - astrange 12y ago
    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.

by krylon 12y ago

jleyank 12y ago

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.

kragen 12y ago
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.

nomel 12y ago

Just curious, was this a CPU bound program?

krylon 12y ago
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.)
- deleted 12y ago
  [deleted]

gsg 12y ago

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

danieldk 12y ago

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])

krylon 12y ago
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.
- astrange 12y ago
  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.