3 ms·

- Programming language does matter. You will not be able to get the same performance in any programming language you choose. - Abstractions are the enemy of p

by YZF 10y ago

- Programming language does matter. You will not be able to get the same performance in any programming language you choose. - Abstractions are the enemy of performance. You can't get high performance through many layers of abstraction. This relates to my previous point. - Algorithmic complexity matters when dealing with large data sets. Abstractions can hide the true complexity. (e.g. the famous string append example from IIRC Joel Spolsky). So the key to high performance software is: - As close as possible to the hardware. - The right data structures/layout (taking into account the hardware). - The right algorithms. - Measure properly and optimize.

sshumaker 10y ago
I think your point around abstractions could be more nuanced. The wrong abstractions can be deleterious to performance, thoughtfully chosen ones can actually be beneficial. Every programming language is several layers of abstraction above the hardware it runs on, which gives the compiler opportunities for optimization, or even the superscalar CPU opportunities for parallelization / reordering. And so on.
- YZF 10y ago
  I've yet to see a compiler that can beat a human hand-optimizing. It's true that for zero effort the compiler can usually do better but if you really care about performance you need to get around those abstractions. I worked on a wavelet video decoder, after a while we had a pretty optimized C code that used SSE intrinsics for large portions of the decode. Some clever guy spent 3 months and rewrote the entire decoder in assembly. It involved careful data layout and optimizing the instruction sequences. It ran more than twice as fast than our hand optimized C code. Same algorithm, input and output.
flukus 10y ago
I'd make that last key number 1.
taneq 10y ago
> Abstractions are the enemy of performance. You can't get high performance through many layers of abstraction. This relates to my previous point. This depends on the kind of abstraction. Layers and layers of crap will never be fast. The correct stack of abstractions, which map well to your problem space, will usually make your code faster because they will make it easier for you to see higher-level optimizations. > Algorithmic complexity matters when dealing with large data sets. Abstractions can hide the true complexity. (e.g. the famous string append example from IIRC Joel Spolsky). Very true. Abstractions are a tool to help understand the problem space, not an excuse to avoid understanding it. > Measure properly and optimize. A+. If you can't measure it, you can't control it. It boggles me how many people don't get this. "I replaced all the floating point math with integer math because integer math is faster." Really? IS IT? How do you KNOW? Did you benchmark it? "No but..." ahem sorry, I've had this argument too many times. :P
cottonseed 10y ago
> Abstractions are the enemy of performance. I like to say "abstractions + compilers = performance".

by YZF 10y ago

sshumaker 10y ago

I think your point around abstractions could be more nuanced. The wrong abstractions can be deleterious to performance, thoughtfully chosen ones can actually be beneficial. Every programming language is several layers of abstraction above the hardware it runs on, which gives the compiler opportunities for optimization, or even the superscalar CPU opportunities for parallelization / reordering. And so on.

YZF 10y ago
I've yet to see a compiler that can beat a human hand-optimizing. It's true that for zero effort the compiler can usually do better but if you really care about performance you need to get around those abstractions. I worked on a wavelet video decoder, after a while we had a pretty optimized C code that used SSE intrinsics for large portions of the decode. Some clever guy spent 3 months and rewrote the entire decoder in assembly. It involved careful data layout and optimizing the instruction sequences. It ran more than twice as fast than our hand optimized C code. Same algorithm, input and output.

flukus 10y ago

I'd make that last key number 1.

taneq 10y ago

> Abstractions are the enemy of performance. You can't get high performance through many layers of abstraction. This relates to my previous point. This depends on the kind of abstraction. Layers and layers of crap will never be fast. The correct stack of abstractions, which map well to your problem space, will usually make your code faster because they will make it easier for you to see higher-level optimizations. > Algorithmic complexity matters when dealing with large data sets. Abstractions can hide the true complexity. (e.g. the famous string append example from IIRC Joel Spolsky). Very true. Abstractions are a tool to help understand the problem space, not an excuse to avoid understanding it. > Measure properly and optimize. A+. If you can't measure it, you can't control it. It boggles me how many people don't get this. "I replaced all the floating point math with integer math because integer math is faster." Really? IS IT? How do you KNOW? Did you benchmark it? "No but..." ahem sorry, I've had this argument too many times. :P

cottonseed 10y ago

> Abstractions are the enemy of performance. I like to say "abstractions + compilers = performance".