4 ms·

All this advice against "premature optimization" has created generations of programmers that don't understand how to use hardware efficiently. Here's the probl

All this advice against "premature optimization" has created generations of programmers that don't understand how to use hardware efficiently. Here's the problem: If you profile software that is 100x slower than it needs to be on every level, there are no obvious bottlenecks. Your whole program is just slow across the board, because you used tons of allocations, abstractions and indirections at every step of the way. Rob Pike probably has never written a program where performance really mattered, because if he did, he would've found that you need to think about performance right from the beginning and all the way during development, because making bad decisions early on can force you to rewrite almost everything. For instance, if you start writing a Go program with the mindset that you can just heap-allocate all the time, the garbage collector will eventually come back to bite you and the "bottleneck" will be your entire codebase.

byronr 6y ago
> Rob Pike probably has never written a program where performance really mattered Rob Pike has written window system software which ran in what now would be called a "thin client" over a 9600 baud modem and rendered graphics using a 2MHz CPU. He probably knows a thing or two about performance tuning.
- gridlockd 6y ago
  By "rendered graphics" you mean "place characters on screen"? If the bottleneck for that is a 9600 baud modem throughput, there's not a lot you need to optimize, even on a 2MHZ CPU. Also, having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance on modern hardware with completely different capabilities. In fact, it's probably what causes you to develop a "computers are so fast now, no need to think about performance"-mindset, because everything you want to do could be done in an arbitrarily inefficient way on modern hardware. Performance doesn't matter to you anymore.
  - zimpenfish 6y ago
    > By "rendered graphics" you mean "place characters on screen"? It was a fully graphical 800x1024 (or 1024x1024) system running on 1982 processors. https://en.wikipedia.org/wiki/Blit_(computer_terminal) https://en.wikipedia.org/wiki/Blit_(computer_terminal) > having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance Perhaps not but it does mean you've "written a program where performance really mattered" which I believe was the original claim?
    - gridlockd 6y ago
      > It was a fully graphical 800x1024 (or 1024x1024) system running on 1982 processors. I've looked into in that. Blit was monochrome, had an 8Mhz processor, and a relatively large 256KB framebuffer which could but directly written to. There were only a handful commands, mostly concerned with copying (blitting) bitmaps around. Rob Pike only wrote the first version of the graphics routines - the slowest version, in C(!). It was rewritten another four times over, by Locanthi and finally Reiser. I don't think any credit should go to Pike for implementing the performance-critical parts of that system. https://9p.io/cm/cs/doc/87/archtr.ps.gz https://9p.io/cm/cs/doc/87/archtr.ps.gz > Perhaps not but it does mean you've "written a program where performance really mattered" which I believe was the original claim? No, it doesn't mean that. You can be wasteful on constrained hardware as well, performance doesn't necessarily matter even on the simplest chips, if what you want to do doesn't need the full capabilities of the system. However, I am specifically replying to the claim that "Rob Pike probably knows a thing or two about performance". As you can see, Rob Pike handed off performance-critical work to someone else. He probably didn't know how to write optimal code for that particular platform, but even if he did, most of that knowledge wouldn't transfer over to modern systems. At the very least, he didn't care about optimizing that stuff, or he wouldn't have handed it off. He would've enjoyed optimizing that stuff. And that's all completely fine, not every programmer needs to care about performance. I just refuse to take advice from these people about performance or "premature optimization", because it is uninformed.
      - byronr 6y ago
        Writeup of the blit terminal's operating system is here, it consists of a lot more than the bitblt primitive, with many whole-system performance concerns at play: http://a.papnet.eu/UNIX/bltj/06771910.pdf http://a.papnet.eu/UNIX/bltj/06771910.pdf Suggest you read this before denigrating Rob Pike's bona fides. Not sure what axe you are trying to grind but it is ugly and unbecoming of a professional.
  - enneff 6y ago
    > In fact, it's probably what causes you to develop a "computers are so fast now, no need to think about performance"-mindset This is the complete opposite of Rob’s mindset, which you’d know if you had any familiarity with his work.
  - mturmon 6y ago
    Your reply here saddens me. I suggest you look up Rob Pike and reconsider some of your hypotheticals about what he knows about. (https://en.wikipedia.org/wiki/Rob_Pike https://en.wikipedia.org/wiki/Rob_Pike)
    - deleted 6y ago
      [deleted]
hnick 6y ago
> Here's the problem: If you profile software that is 100x slower than it needs to be on every level, there are no obvious bottlenecks. Your whole program is just slow across the board, because you used tons of allocations, abstractions and indirections at every step of the way. Oh this hurts. I work with a system in Perl that is just kinda slow. Too slow to be good but not slow enough to be useless. Slow enough that if it crashes we have trouble getting things reprocessed in a reasonable time, there's no fat built in to our timelines. Anyway I've profiled it many times and found exactly what you said. Layers and layers of OO soup, functions calling functions calling functions. There are no obvious improvements. It's overhead, not code.

byronr 6y ago

> Rob Pike probably has never written a program where performance really mattered Rob Pike has written window system software which ran in what now would be called a "thin client" over a 9600 baud modem and rendered graphics using a 2MHz CPU. He probably knows a thing or two about performance tuning.

gridlockd 6y ago
By "rendered graphics" you mean "place characters on screen"? If the bottleneck for that is a 9600 baud modem throughput, there's not a lot you need to optimize, even on a 2MHZ CPU. Also, having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance on modern hardware with completely different capabilities. In fact, it's probably what causes you to develop a "computers are so fast now, no need to think about performance"-mindset, because everything you want to do could be done in an arbitrarily inefficient way on modern hardware. Performance doesn't matter to you anymore.
- zimpenfish 6y ago
  > By "rendered graphics" you mean "place characters on screen"? It was a fully graphical 800x1024 (or 1024x1024) system running on 1982 processors. https://en.wikipedia.org/wiki/Blit_(computer_terminal) https://en.wikipedia.org/wiki/Blit_(computer_terminal) > having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance Perhaps not but it does mean you've "written a program where performance really mattered" which I believe was the original claim?
  - gridlockd 6y ago
    > It was a fully graphical 800x1024 (or 1024x1024) system running on 1982 processors. I've looked into in that. Blit was monochrome, had an 8Mhz processor, and a relatively large 256KB framebuffer which could but directly written to. There were only a handful commands, mostly concerned with copying (blitting) bitmaps around. Rob Pike only wrote the first version of the graphics routines - the slowest version, in C(!). It was rewritten another four times over, by Locanthi and finally Reiser. I don't think any credit should go to Pike for implementing the performance-critical parts of that system. https://9p.io/cm/cs/doc/87/archtr.ps.gz https://9p.io/cm/cs/doc/87/archtr.ps.gz > Perhaps not but it does mean you've "written a program where performance really mattered" which I believe was the original claim? No, it doesn't mean that. You can be wasteful on constrained hardware as well, performance doesn't necessarily matter even on the simplest chips, if what you want to do doesn't need the full capabilities of the system. However, I am specifically replying to the claim that "Rob Pike probably knows a thing or two about performance". As you can see, Rob Pike handed off performance-critical work to someone else. He probably didn't know how to write optimal code for that particular platform, but even if he did, most of that knowledge wouldn't transfer over to modern systems. At the very least, he didn't care about optimizing that stuff, or he wouldn't have handed it off. He would've enjoyed optimizing that stuff. And that's all completely fine, not every programmer needs to care about performance. I just refuse to take advice from these people about performance or "premature optimization", because it is uninformed.
    - byronr 6y ago
      Writeup of the blit terminal's operating system is here, it consists of a lot more than the bitblt primitive, with many whole-system performance concerns at play: http://a.papnet.eu/UNIX/bltj/06771910.pdf http://a.papnet.eu/UNIX/bltj/06771910.pdf Suggest you read this before denigrating Rob Pike's bona fides. Not sure what axe you are trying to grind but it is ugly and unbecoming of a professional.
- enneff 6y ago
  > In fact, it's probably what causes you to develop a "computers are so fast now, no need to think about performance"-mindset This is the complete opposite of Rob’s mindset, which you’d know if you had any familiarity with his work.
- mturmon 6y ago
  Your reply here saddens me. I suggest you look up Rob Pike and reconsider some of your hypotheticals about what he knows about. (https://en.wikipedia.org/wiki/Rob_Pike https://en.wikipedia.org/wiki/Rob_Pike)
  - deleted 6y ago
    [deleted]

hnick 6y ago

> Here's the problem: If you profile software that is 100x slower than it needs to be on every level, there are no obvious bottlenecks. Your whole program is just slow across the board, because you used tons of allocations, abstractions and indirections at every step of the way. Oh this hurts. I work with a system in Perl that is just kinda slow. Too slow to be good but not slow enough to be useless. Slow enough that if it crashes we have trouble getting things reprocessed in a reasonable time, there's no fat built in to our timelines. Anyway I've profiled it many times and found exactly what you said. Layers and layers of OO soup, functions calling functions calling functions. There are no obvious improvements. It's overhead, not code.