5 ms·

"Premature optimization is the root of all evil" -- Donald Knuth What works for i386 may not be applicable on arm/hppa/ppc/etc. It should not even matter thes

"Premature optimization is the root of all evil" -- Donald Knuth What works for i386 may not be applicable on arm/hppa/ppc/etc. It should not even matter these days as almost every CPU clocks well over 1000MHz. If that is still not enough, extra cloud instances are probably cheaper than wasting your time with extensive profiling and manual optimizations.

StefanKarpinski 12y ago
I'm so tired of people trotting this quote out. We get it – you don't care about performance – hardware is fast and your problems are easy. But there are people who have difficult problems to solve – some hard enough that the limits of what hardware can do represent a real constraint. For those people, having a deep understanding of hardware and performance is essential.
- AuntTillie 12y ago
  Feel free to dismiss what you already know, I am sure the world would be a better place if everyone was as wise as you.
- dang 12y ago
  I couldn't agree more. It is the most pre-fab of dismissals and takes threads like this in precisely the wrong direction: into generic goo, when we ought to be discussing salient details, like the impact of varying page alignments. Few of us have anything substantive to say about that, which is fine—but then we ought to post nothing, not regurgitate truisms.
wongarsu 12y ago
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." -- Donald Knuth (My emphasis) Donald Knuth was clearly for optimizing software, he merely said that you should profile before you optimize. The author is clearly profiling his code, and there's nothing wrong with getting more out of the hardware you paid for.
- AuntTillie 12y ago
  "Page align everything" by convention is in fact a form of optimization without profiling. TFA explains in detail why this is yet another bad idea, perhaps you read something in my comment I did not write?
  - innocenat 12y ago
    That is ridiculous. Page align everything can easily be a leftover code that is fast for old CPU, as you said in your original content. You would still call that premature optimization? Or you think that every time new processor is released, you must re-profile all your original code to see whether the old optimization still solve the hot path?
    - erikarn 12y ago
      TL;DR - yes.
  - LnxPrgr3 12y ago
    Probably the part where you said, "If that is still not enough, extra cloud instances are probably cheaper than wasting your time with extensive profiling and manual optimizations." At least profiling showed the author why page aligning all the things is silly. I have yet to work on an architecture where it isn't at best a waste of time, so I'm not sure why the measurement was necessary, but hey—running the test cured a potential delusion. I also have yet to work on a system that can talk over the network faster than it can to another core that shares a layer of cache with it. Besides, hardware savings are multiplied over all your customers—it's only 1:1 if you're working on software for a single entity. If that's your case, then you're probably right—any time on making quality software is probably wasted because few will benefit, and hardware probably is cheaper than dev time. That's not the world everyone lives in, though.
    - AuntTillie 12y ago
      Quite right, but if you ship software to customers you'd have to profile on a variety of CPUs or risk regressing on other models. Profiling on recent Intel x86_64 CPUs gave me the (perhaps false) impression TFA author writes for a known or even controlled environment. That is indeed not a luxury everyone enjoys, so I raised a portability concern. However, the potential benefits of cheap horizontal scaling also extends to said customers.
to3m 12y ago
The funny thing: in fact, it will work, and for exactly the same reasons. The manual describes it thus: "The conflicting condition is a stride determined by the size of the cache in bytes, divided by the number of ways." L1 caches for most modern CPUs work in this manner, and you see the same result. (Wikipedia has a description - http://en.wikipedia.org/wiki/CPU_cache http://en.wikipedia.org/wiki/CPU_cache - the type of cache commonly employed today being the N-way set associative type.) You can run the same calculations to get an equivalent value for each CPU. For example, you asked about HPPA: for a PA8700, this value would - I suppose... I just found the cache specification using Google :) - be 384KBytes, as its data cache is 1.5MBytes 4-way set associative. As a more general note: If you try to seriously solve performance problems, you'll quickly find, as I always have, that there's little basis in reality for the idea that they can be fixed late in the day with a few spot hacks. Indeed, that idea is usually the reason the problems have arisen in the first place. But that idea has to be the basis of any doctrine of adopting a just-in-time policy for performance problems! So if you're not a big fan of programming with performance in mind, then I do think you should be celebrating this kind of quick tweak, rather than decrying it. It's evidence for your position.
- AuntTillie 12y ago
  My position is based in pragmatism. Code that works and is delivered in time is often more desirable than code that works, is fast, but delivered late. There's always a cost-benefit tradeoff to be made and if warm bodies yield more performance per buck than cold ones^, that's great for us programmers! As for mindset, page aligned allocations are required to use protection modes and I tend to program more with security in mind. Glad it helps performance, but it could often times be a completely unintentional side effect. Thanks for your insights, though. Appreciated! ^: Assuming they're at present in idle (or off) state.
wglb 12y ago
Yet Knuth is one of the greater optimizers of all time with his combinatorial work. I ran into this myself writing a muscle tremor filter to run in real time in an ECG data collection system in 1970. The point was to drop the phone call from the patient's bedside if there was too much tremor interference from the patient. There just wasn't enough CPU bandwidth to handle very much processing. So the first version tried to be quite fast. But it turned out that it gave false positives as well as false negatives. No shipping of that sucker. I made up a rule for performance-critical software: "First, make it right, then make it fast". I am curious what about the article suggests that the optimization is premature? Do you mean to say that one should never worry about optimization?

StefanKarpinski 12y ago

I'm so tired of people trotting this quote out. We get it – you don't care about performance – hardware is fast and your problems are easy. But there are people who have difficult problems to solve – some hard enough that the limits of what hardware can do represent a real constraint. For those people, having a deep understanding of hardware and performance is essential.

AuntTillie 12y ago
Feel free to dismiss what you already know, I am sure the world would be a better place if everyone was as wise as you.
dang 12y ago
I couldn't agree more. It is the most pre-fab of dismissals and takes threads like this in precisely the wrong direction: into generic goo, when we ought to be discussing salient details, like the impact of varying page alignments. Few of us have anything substantive to say about that, which is fine—but then we ought to post nothing, not regurgitate truisms.

wongarsu 12y ago

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." -- Donald Knuth (My emphasis) Donald Knuth was clearly for optimizing software, he merely said that you should profile before you optimize. The author is clearly profiling his code, and there's nothing wrong with getting more out of the hardware you paid for.

AuntTillie 12y ago
"Page align everything" by convention is in fact a form of optimization without profiling. TFA explains in detail why this is yet another bad idea, perhaps you read something in my comment I did not write?
- innocenat 12y ago
  That is ridiculous. Page align everything can easily be a leftover code that is fast for old CPU, as you said in your original content. You would still call that premature optimization? Or you think that every time new processor is released, you must re-profile all your original code to see whether the old optimization still solve the hot path?
  - erikarn 12y ago
    TL;DR - yes.
- LnxPrgr3 12y ago
  Probably the part where you said, "If that is still not enough, extra cloud instances are probably cheaper than wasting your time with extensive profiling and manual optimizations." At least profiling showed the author why page aligning all the things is silly. I have yet to work on an architecture where it isn't at best a waste of time, so I'm not sure why the measurement was necessary, but hey—running the test cured a potential delusion. I also have yet to work on a system that can talk over the network faster than it can to another core that shares a layer of cache with it. Besides, hardware savings are multiplied over all your customers—it's only 1:1 if you're working on software for a single entity. If that's your case, then you're probably right—any time on making quality software is probably wasted because few will benefit, and hardware probably is cheaper than dev time. That's not the world everyone lives in, though.
  - AuntTillie 12y ago
    Quite right, but if you ship software to customers you'd have to profile on a variety of CPUs or risk regressing on other models. Profiling on recent Intel x86_64 CPUs gave me the (perhaps false) impression TFA author writes for a known or even controlled environment. That is indeed not a luxury everyone enjoys, so I raised a portability concern. However, the potential benefits of cheap horizontal scaling also extends to said customers.

to3m 12y ago

The funny thing: in fact, it will work, and for exactly the same reasons. The manual describes it thus: "The conflicting condition is a stride determined by the size of the cache in bytes, divided by the number of ways." L1 caches for most modern CPUs work in this manner, and you see the same result. (Wikipedia has a description - http://en.wikipedia.org/wiki/CPU_cache http://en.wikipedia.org/wiki/CPU_cache - the type of cache commonly employed today being the N-way set associative type.) You can run the same calculations to get an equivalent value for each CPU. For example, you asked about HPPA: for a PA8700, this value would - I suppose... I just found the cache specification using Google :) - be 384KBytes, as its data cache is 1.5MBytes 4-way set associative. As a more general note: If you try to seriously solve performance problems, you'll quickly find, as I always have, that there's little basis in reality for the idea that they can be fixed late in the day with a few spot hacks. Indeed, that idea is usually the reason the problems have arisen in the first place. But that idea has to be the basis of any doctrine of adopting a just-in-time policy for performance problems! So if you're not a big fan of programming with performance in mind, then I do think you should be celebrating this kind of quick tweak, rather than decrying it. It's evidence for your position.

AuntTillie 12y ago
My position is based in pragmatism. Code that works and is delivered in time is often more desirable than code that works, is fast, but delivered late. There's always a cost-benefit tradeoff to be made and if warm bodies yield more performance per buck than cold ones^, that's great for us programmers! As for mindset, page aligned allocations are required to use protection modes and I tend to program more with security in mind. Glad it helps performance, but it could often times be a completely unintentional side effect. Thanks for your insights, though. Appreciated! ^: Assuming they're at present in idle (or off) state.

wglb 12y ago

Yet Knuth is one of the greater optimizers of all time with his combinatorial work. I ran into this myself writing a muscle tremor filter to run in real time in an ECG data collection system in 1970. The point was to drop the phone call from the patient's bedside if there was too much tremor interference from the patient. There just wasn't enough CPU bandwidth to handle very much processing. So the first version tried to be quite fast. But it turned out that it gave false positives as well as false negatives. No shipping of that sucker. I made up a rule for performance-critical software: "First, make it right, then make it fast". I am curious what about the article suggests that the optimization is premature? Do you mean to say that one should never worry about optimization?