5 ms·

You can easily beat a good compiler for many kinds of code. It just takes time, effort and a good deal of knowledge. If you're doing it outside of the hottest k

by ori_b 16y ago

You can easily beat a good compiler for many kinds of code. It just takes time, effort and a good deal of knowledge. If you're doing it outside of the hottest kernels of your code, you're probably wasting your time.

kenjackson 16y ago
And it also requires that you pay attention to your evolving toolset. I've worked on x86 code that was hand-optimized back in 1995. Once I reverse-engineered it and handed it to Visual C++ the code gen'ned by VC killed it, by like a factor of 2x. I emailed the code to the guy who originally wrote it and his response was brief, "The compiler wasn't that smart before". But yet the code sat there for like 10 years, untouched -- largely because people don't like to touch x86 assembly code that is working. The moral, you may get a benefit today, but you don't get any future benefits of the investment at MS, Intel, the Gcc folks, etc..., who are improving the compilers. Sometimes it is the right call to hand optimize. But when you do, I suggest having a C/C++ version alongside of it that one can test aganist it whenever the compiler revs.
- metaguri 16y ago
  That's a great point. It's similar to why people often set up their problems as 3SAT or convex optimizations--you get to benefit from all future improvements to 3SAT solvers or optimizers.
- deleted 16y ago
  [deleted]
- zbyszek 16y ago
  An anecdote in a similar vein: I was involved in writing (Fortran) code for Crays in the 90s. For the T3D, we speeded up the code with the usual set of tricks -- loop unrolling, array padding and so on. With the later T3E, it turned out that not only could the compiler now do all that, but that code hand-optimised in this way performed worse.
  - kenjackson 16y ago
    Heh, we may know each other. I also developed code on the T3D and T3E. I figure can't be too many people in the world that developed for both. I still have the big gray Cray binders with the documentation laying around somewhere.
smcl 16y ago
Heh, I do like the "You can easily beat...." followed imediately by "It just takes time, effort..." - but you're absolutely right. I'm not sure that was his point though, coaxing the compiler into issuing better code by providing few hints doesn't necessarily require too much time or effort.
- gridspy 16y ago
  Moral of the story - if you can make more assumptions about the input data than the compiler, you can beat it. Or in general - if you are considering using a tool or rolling your own, what do you know about your data that the tool author doesn't?

by ori_b 16y ago

kenjackson 16y ago

And it also requires that you pay attention to your evolving toolset. I've worked on x86 code that was hand-optimized back in 1995. Once I reverse-engineered it and handed it to Visual C++ the code gen'ned by VC killed it, by like a factor of 2x. I emailed the code to the guy who originally wrote it and his response was brief, "The compiler wasn't that smart before". But yet the code sat there for like 10 years, untouched -- largely because people don't like to touch x86 assembly code that is working. The moral, you may get a benefit today, but you don't get any future benefits of the investment at MS, Intel, the Gcc folks, etc..., who are improving the compilers. Sometimes it is the right call to hand optimize. But when you do, I suggest having a C/C++ version alongside of it that one can test aganist it whenever the compiler revs.

metaguri 16y ago
That's a great point. It's similar to why people often set up their problems as 3SAT or convex optimizations--you get to benefit from all future improvements to 3SAT solvers or optimizers.
deleted 16y ago
[deleted]
zbyszek 16y ago
An anecdote in a similar vein: I was involved in writing (Fortran) code for Crays in the 90s. For the T3D, we speeded up the code with the usual set of tricks -- loop unrolling, array padding and so on. With the later T3E, it turned out that not only could the compiler now do all that, but that code hand-optimised in this way performed worse.
- kenjackson 16y ago
  Heh, we may know each other. I also developed code on the T3D and T3E. I figure can't be too many people in the world that developed for both. I still have the big gray Cray binders with the documentation laying around somewhere.

smcl 16y ago

Heh, I do like the "You can easily beat...." followed imediately by "It just takes time, effort..." - but you're absolutely right. I'm not sure that was his point though, coaxing the compiler into issuing better code by providing few hints doesn't necessarily require too much time or effort.

gridspy 16y ago
Moral of the story - if you can make more assumptions about the input data than the compiler, you can beat it. Or in general - if you are considering using a tool or rolling your own, what do you know about your data that the tool author doesn't?