12 ms·

A couple of weeks ago I'd never heard of Peter Cordes. Now the linked article is the third time I've seen his work. He's doing a fine job of fixing Stackoverflo

A couple of weeks ago I'd never heard of Peter Cordes. Now the linked article is the third time I've seen his work. He's doing a fine job of fixing Stackoverflow's low-level optimization knowledge. Not so long ago all I seemed to find there was people saying something like, "well, you shouldn't optimize that anyway", or, "modern computers are very complex, don't even try to understand what's happening".

fhood 9y ago
> "modern computers are very complex, don't even try to understand what's happening" I live my life by that adage
mark-r 9y ago
If I ever see Knuth's quote "premature optimization is the root of all evil" in response to a question again, I think I'll puke. Not only is it hard for outsiders to know what's premature and what isn't, but sometimes it's nice to make a habit of doing things the faster way when you have two choices that are otherwise indistinguishable. For example I try to use ++x instead of x++, even though 99% of the time it makes no difference.
- ww520 9y ago
  Ah, hindsight is 20/20. It's easy to criticize premature optimization after the fact.
- santaclaus 9y ago
  > For example I try to use ++x instead of x++ ++x can be slower, depending on the context -- it introduces a sequence point.
  - mark-r 9y ago
    Really? If you have the time, I'd love an explanation. Or if you can point to some other resource that would be great too.
    - santaclaus 9y ago
      I remember seeing a blog post from Andrei Alexandrescu that I can't seem to dig up, but this SO post seems to be a nice summary [1]. In short, in 99.9999999% of usages post increment is probably better. [1] https://stackoverflow.com/a/38947878 https://stackoverflow.com/a/38947878
      - mark-r 9y ago
        Thanks. I guess I'm applying this rule only when the result of the increment isn't being used directly, so there is no dependency on the operation. When the result is used, the semantic difference between ++x and x++ obviously determines the choice.
    - deleted 9y ago
      [deleted]
    - flamedoge 9y ago
      Just look at the liveness of the expression x+1. post-increment means expression has to be alive before whatever uses '++x' whereas pre-increment can delay until next usage of x.
- gnaritas 9y ago
  > but sometimes it's nice to make a habit of doing things the faster way when you have two choices that are otherwise indistinguishable. That is virtually never the case. > For example I try to use ++x instead of x++ Those have wildly different semantics.
  - colejohnson66 9y ago
    Yes, but if used as their own statement and not used as some bigger expression (parameter to function, etc.), any decent compiler will compile them the same way.
    - gnaritas 9y ago
      Yes, and thus a perfect example premature optimization; semantics should define default usage, not some possible micro optimization. This is exactly the kind of case Knuth is talking about, going around doing ++x because you think it's faster when the standard idiom is x++ is premature optimization.
      - marcosdumay 9y ago
        Well, there is no reason for any standard idiom there. Those `++` and `--` operators are something to avoid anyway.
      - zerr 9y ago
        x++ is not the "standard idiom".
        mark-r 9y ago
        In my experience x++ is far more common than ++x when it doesn't matter which you use, "for" statements for example.
        gnaritas 9y ago
        Yes, it is.
- pjmlp 9y ago
  I rather take "correctness and safety before performance", and only if it doesn't meet the performance criteria of an user story, then with the help of a profiler analyse what are the next steps. 99% of the time I don't need to worry about the profiler.
- vardump 9y ago
  > I try to use ++x instead of x++, even though 99% of the time it makes no difference. I think 100% of time is closer to truth, unless you're using ancient or embedded 8/16-bit compilers.
  - Animats 9y ago
    That hasn't really been a thing since the PDP-11, which had an auto-increment option on the register used for pointer offsets. That's why that feature is in C. It really mattered in 1978.
    - vram22 9y ago
      Interesting, so the C creators used a feature in their language, that was hardware-specific. I thought (from having read K&R) that one goal of C was to be hardware-independent. Maybe this was an exception, or maybe that auto-increment was common to many computer designs at that time.
      - mark-r 9y ago
        Wikipedia states that its inclusion in B (the ancestor to C) was independent of the PDP-11 instruction set, which hadn't been invented yet [1]. [1] https://en.wikipedia.org/wiki/Increment_and_decrement_operators#History https://en.wikipedia.org/wiki/Increment_and_decrement_operat...
        vram22 9y ago
        Cool. Wow, B. A blast from the past, sort of. I had read a good book about BCPL (the ancestor to B) many years ago. IIRC, it was by Martin Richards, inventor of BCPL. Pretty interesting book and language. BCPL and B were both typeless languages, or languages with just one type, the machine word (16 or 32 bits, don't remember). Still I found that many algorithms and programs were expressed rather compactly in BCPL - or so it seemed to me at the time. Was quite junior then, and without exposure to more advanced programming languages - only knew BASIC and Pascal, probably; even C, I only learned a bit later. https://en.wikipedia.org/wiki/B_(programming_language) https://en.wikipedia.org/wiki/B_(programming_language) https://en.wikipedia.org/wiki/BCPL https://en.wikipedia.org/wiki/BCPL https://en.wikipedia.org/wiki/Martin_Richards_(computer_scientist) https://en.wikipedia.org/wiki/Martin_Richards_(computer_scie... Also just saw some other interesting stuff from the BCPL article above: [ BCPL is the language in which the original hello world program was written.[3] The first MUD was also written in BCPL (MUD1). Several operating systems were written partially or wholly in BCPL (for example, TRIPOS and the earliest versions of AmigaDOS). BCPL was also the initial language used in the seminal Xerox PARC Alto project, the first modern personal computer; among other projects, the Bravo document preparation system was written in BCPL. ]
- blockoperation 9y ago
  Writing performant code by using the correct idioms, data structures, algorithms, etc, from the start is just common sense rather than 'premature optimisation'. Writing unreadable, micro-optimised code in the name of performance without even attempting to profile it first is another matter. My personal rule (as a not-very-good hobbyist) is that if I have to refactor everything in order to accommodate an optimisation in a path that's already 'fast enough', or introduce some arcane hackery that only makes sense with comments into otherwise clean code, then it must be backed up with realistic benchmarks (and show a significant improvement).
- npsimons 9y ago
  > Not only is it hard for outsiders to know what's premature and what isn't, My rule of thumb is if you haven't profiled it, it's premature to try and optimize it. > but sometimes it's nice to make a habit of doing things the faster way when you have two choices that are otherwise indistinguishable. Now this is a good habit to be in.
  - mark-r 9y ago
    > My rule of thumb is if you haven't profiled it, it's premature to try and optimize it. The context was specifically about questions on StackOverflow. You don't know if the person asking the question has profiled it or not, and the assumption is often that they haven't. Probably true more often than not, but very condescending and unhelpful to the person who has.
- nulagrithom 9y ago
  In my opinion, any optimization done before taking the naive approach is usually premature optimization. That might sound a little extreme, but in the past 5 years I've run into exactly 1 problem that was solved by busting out the profiler and optimizing. In that same time, I can't count on all my digits the number of features that didn't ship, estimates that were overshot, deadlines that were slipped, etc etc. I've even been part of a team that ran out of runway while popping open jsPerf to choose between !! and Boolean(). Our app was fast as hell -- too bad no one will ever get to use it. If you're expending cycles choosing between ++x and x++ and you're not ahead of schedule, please stop.
  - mark-r 9y ago
    That was my point, I'm not expending cycles choosing between ++x and x++. I've just chosen a different default than most of the code I've seen, and you still need to realize when the default doesn't do what you want - but that's usually obvious. Sorry to hear about your unsuccessful projects, that's a bummer. I hope that premature optimization wasn't a major part of the blame for any of them.
    - ben0x539 9y ago
      It's so irritating that golang has x++ but not ++x. I never remember until shit isn't compiling. Grr!
  - laythea 9y ago
    This vastly differs depending on what software you write. I have done lots of necessary performance optimizations. Of course, there is a balance. To say never first optimize, is as bad as optimizing everything, in my opinion. It should require a case by case "study" of whether it is worth it. This kind of judgement comes with experience.
- benchaney 9y ago
  I was with you until you got to the ++x/x++ example. It is a bad example because they generate the same machine code except in situations where they are semantically different.
  - mark-r 9y ago
    For simple types that's true, and that's part of the 99% I was talking about. Where it makes a difference is class types, C++ iterators being a prime example. Maybe the optimizer can make the two cases generate identical code, but why take the chance? I chose that example because it didn't need a full paragraph to explain, but you're right that there are probably better ones. Edit: maybe a Python example? ''.join([a, b, c]) is faster than a + b + c, but again 99% of the time you won't be using it in performance critical code. But it's a useful idiom to know.
    - jacobolus 9y ago
      From what I remember, for such small examples, a + b + c is significantly faster. (The CPython folks might have done some optimization work on this a few years back?) It’s only if you plan to concatenate a whole lot of strings that join is a clear winner.
- jcelerier 9y ago
  especially considering that people usually do not quote the following part of the quote : "Yet we should not pass up our opportunities in that critical 3%".
- ksk 9y ago
  Anything one line is prone to being misinterpreted. IMO, people who're still learning shouldn't be bombarded with a million different things, so one liners work for them. People who're experienced, realize the intent of that one liner and will easily know enough to know when it applies.
jdcarter 9y ago
> "modern computers are very complex, don't even try to understand what's happening" One thing to keep in mind is that the CPU is no longer the CPU you think it is. While the x86 instruction set used to directly control the processor, today it's just a compatibility shim. Under the covers, the CPU is converting your assembly into its own microcode and it's that microcode which is doing the real work. For example, look at some of the block diagrams in section 2 of this Intel manual: https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf https://software.intel.com/sites/default/files/managed/a4/60... Combine that with all kinds of other voodoo they've added--fancy caches, branch prediction, and so forth--and the "don't even try" maxim starts to make sense. I'd amend that to say "don't even try unless you're just curious." Personally, I think assembly is a great learning tool, e.g. for understanding how pointers work, how the stack works vs. the heap, how function calls work, and so-forth. I was exposed to Motorola 68K assembly in college and it completely changed my world--lots of C++ things I considered voodoo suddenly made total sense. But I've never used assembly in production code and probably never will.
- dws 9y ago
  The CPU is no longer the CPU that the CPU designers (often) think it is. A few years back someone who worked on CPUs at Intel related how his group pulling their hair out trying to characterize how a small section of code in a loop could have wildly different performance characteristics depending on the preceding instructions.
- mark-r 9y ago
  The Motorola 68K was nearly ideal for assembly programming. You're lucky to have learned on it.
  - jdcarter 9y ago
    Oh very much so, 68K was great. Even better, at my first job we had a custom 68K-based embedded device and no source-level debugger, so you could only debug in assembly. That reinforced everything I had learned just a few years before. Our next device was MIPS-based, and MIPS was a great RISC system to learn on. I count myself very blessed.
setzer22 9y ago
> Not so long ago all I seemed to find there was people saying something like, "well, you shouldn't optimize that anyway I find this "Why would you even do that?" attitude in StackOverflow to be very irritating. And it's not just in low-level optimization questions. StackOverflow should be a place for questions and answers, not a collection of lessons on corporate best practices where curiosity and experimentation is discouraged.
- jimmaswell 9y ago
  I've had the same annoyance in IRC channels - getting an unhelpful lecture on the right way to do things from people who don't fully understand the use case or that "best practices" might not always be worth it or matter, especially in a small script/application
  - ryandrake 9y ago
    I agree. Programming forums are full of this crap. I hate asking a pretty straightforward question online and getting that patronizing "But what are you really trying to do?" response. What I'm really trying to do is get an answer to this specific question. I'm not asking you to re-think my problem statement. Thanks for not helping.
    - eXpl0it3r 9y ago
      At the same time we're getting a lot of people with XY-problems. They think they know what the problem is and they think they know what they about have to do, while the real problem is somewhere else. If someone's intend with an asked question isn't clear, then "But what are you really trying to do?" is a valid question. It's impossible for anyone to just know what you're intentions are and whether you understand the deeper semantics of a problem. More often than not, people try to do things for the wrong reasons.
    - colomon 9y ago
      I dunno, I've been on both sides of this. I agree it's really annoying when someone waltzes around without answering my question. But I've also seen people asking questions which sounded goofy to me, and when you finally get them to tell you want they are actually trying to do, there's a much easier and more direct approach.

fhood 9y ago

> "modern computers are very complex, don't even try to understand what's happening" I live my life by that adage

mark-r 9y ago

If I ever see Knuth's quote "premature optimization is the root of all evil" in response to a question again, I think I'll puke. Not only is it hard for outsiders to know what's premature and what isn't, but sometimes it's nice to make a habit of doing things the faster way when you have two choices that are otherwise indistinguishable. For example I try to use ++x instead of x++, even though 99% of the time it makes no difference.

ww520 9y ago
Ah, hindsight is 20/20. It's easy to criticize premature optimization after the fact.
santaclaus 9y ago
> For example I try to use ++x instead of x++ ++x can be slower, depending on the context -- it introduces a sequence point.
- mark-r 9y ago
  Really? If you have the time, I'd love an explanation. Or if you can point to some other resource that would be great too.
  - santaclaus 9y ago
    I remember seeing a blog post from Andrei Alexandrescu that I can't seem to dig up, but this SO post seems to be a nice summary [1]. In short, in 99.9999999% of usages post increment is probably better. [1] https://stackoverflow.com/a/38947878 https://stackoverflow.com/a/38947878
    - mark-r 9y ago
      Thanks. I guess I'm applying this rule only when the result of the increment isn't being used directly, so there is no dependency on the operation. When the result is used, the semantic difference between ++x and x++ obviously determines the choice.
  - deleted 9y ago
    [deleted]
  - flamedoge 9y ago
    Just look at the liveness of the expression x+1. post-increment means expression has to be alive before whatever uses '++x' whereas pre-increment can delay until next usage of x.
gnaritas 9y ago
> but sometimes it's nice to make a habit of doing things the faster way when you have two choices that are otherwise indistinguishable. That is virtually never the case. > For example I try to use ++x instead of x++ Those have wildly different semantics.
- colejohnson66 9y ago
  Yes, but if used as their own statement and not used as some bigger expression (parameter to function, etc.), any decent compiler will compile them the same way.
  - gnaritas 9y ago
    Yes, and thus a perfect example premature optimization; semantics should define default usage, not some possible micro optimization. This is exactly the kind of case Knuth is talking about, going around doing ++x because you think it's faster when the standard idiom is x++ is premature optimization.
    - marcosdumay 9y ago
      Well, there is no reason for any standard idiom there. Those `++` and `--` operators are something to avoid anyway.
    - zerr 9y ago
      x++ is not the "standard idiom".
      - mark-r 9y ago
        In my experience x++ is far more common than ++x when it doesn't matter which you use, "for" statements for example.
      - gnaritas 9y ago
        Yes, it is.
pjmlp 9y ago
I rather take "correctness and safety before performance", and only if it doesn't meet the performance criteria of an user story, then with the help of a profiler analyse what are the next steps. 99% of the time I don't need to worry about the profiler.
vardump 9y ago
> I try to use ++x instead of x++, even though 99% of the time it makes no difference. I think 100% of time is closer to truth, unless you're using ancient or embedded 8/16-bit compilers.
- Animats 9y ago
  That hasn't really been a thing since the PDP-11, which had an auto-increment option on the register used for pointer offsets. That's why that feature is in C. It really mattered in 1978.
  - vram22 9y ago
    Interesting, so the C creators used a feature in their language, that was hardware-specific. I thought (from having read K&R) that one goal of C was to be hardware-independent. Maybe this was an exception, or maybe that auto-increment was common to many computer designs at that time.
    - mark-r 9y ago
      Wikipedia states that its inclusion in B (the ancestor to C) was independent of the PDP-11 instruction set, which hadn't been invented yet [1]. [1] https://en.wikipedia.org/wiki/Increment_and_decrement_operators#History https://en.wikipedia.org/wiki/Increment_and_decrement_operat...
      - vram22 9y ago
        Cool. Wow, B. A blast from the past, sort of. I had read a good book about BCPL (the ancestor to B) many years ago. IIRC, it was by Martin Richards, inventor of BCPL. Pretty interesting book and language. BCPL and B were both typeless languages, or languages with just one type, the machine word (16 or 32 bits, don't remember). Still I found that many algorithms and programs were expressed rather compactly in BCPL - or so it seemed to me at the time. Was quite junior then, and without exposure to more advanced programming languages - only knew BASIC and Pascal, probably; even C, I only learned a bit later. https://en.wikipedia.org/wiki/B_(programming_language) https://en.wikipedia.org/wiki/B_(programming_language) https://en.wikipedia.org/wiki/BCPL https://en.wikipedia.org/wiki/BCPL https://en.wikipedia.org/wiki/Martin_Richards_(computer_scientist) https://en.wikipedia.org/wiki/Martin_Richards_(computer_scie... Also just saw some other interesting stuff from the BCPL article above: [ BCPL is the language in which the original hello world program was written.[3] The first MUD was also written in BCPL (MUD1). Several operating systems were written partially or wholly in BCPL (for example, TRIPOS and the earliest versions of AmigaDOS). BCPL was also the initial language used in the seminal Xerox PARC Alto project, the first modern personal computer; among other projects, the Bravo document preparation system was written in BCPL. ]
blockoperation 9y ago
Writing performant code by using the correct idioms, data structures, algorithms, etc, from the start is just common sense rather than 'premature optimisation'. Writing unreadable, micro-optimised code in the name of performance without even attempting to profile it first is another matter. My personal rule (as a not-very-good hobbyist) is that if I have to refactor everything in order to accommodate an optimisation in a path that's already 'fast enough', or introduce some arcane hackery that only makes sense with comments into otherwise clean code, then it must be backed up with realistic benchmarks (and show a significant improvement).
npsimons 9y ago
> Not only is it hard for outsiders to know what's premature and what isn't, My rule of thumb is if you haven't profiled it, it's premature to try and optimize it. > but sometimes it's nice to make a habit of doing things the faster way when you have two choices that are otherwise indistinguishable. Now this is a good habit to be in.
- mark-r 9y ago
  > My rule of thumb is if you haven't profiled it, it's premature to try and optimize it. The context was specifically about questions on StackOverflow. You don't know if the person asking the question has profiled it or not, and the assumption is often that they haven't. Probably true more often than not, but very condescending and unhelpful to the person who has.
nulagrithom 9y ago
In my opinion, any optimization done before taking the naive approach is usually premature optimization. That might sound a little extreme, but in the past 5 years I've run into exactly 1 problem that was solved by busting out the profiler and optimizing. In that same time, I can't count on all my digits the number of features that didn't ship, estimates that were overshot, deadlines that were slipped, etc etc. I've even been part of a team that ran out of runway while popping open jsPerf to choose between !! and Boolean(). Our app was fast as hell -- too bad no one will ever get to use it. If you're expending cycles choosing between ++x and x++ and you're not ahead of schedule, please stop.
- mark-r 9y ago
  That was my point, I'm not expending cycles choosing between ++x and x++. I've just chosen a different default than most of the code I've seen, and you still need to realize when the default doesn't do what you want - but that's usually obvious. Sorry to hear about your unsuccessful projects, that's a bummer. I hope that premature optimization wasn't a major part of the blame for any of them.
  - ben0x539 9y ago
    It's so irritating that golang has x++ but not ++x. I never remember until shit isn't compiling. Grr!
- laythea 9y ago
  This vastly differs depending on what software you write. I have done lots of necessary performance optimizations. Of course, there is a balance. To say never first optimize, is as bad as optimizing everything, in my opinion. It should require a case by case "study" of whether it is worth it. This kind of judgement comes with experience.
benchaney 9y ago
I was with you until you got to the ++x/x++ example. It is a bad example because they generate the same machine code except in situations where they are semantically different.
- mark-r 9y ago
  For simple types that's true, and that's part of the 99% I was talking about. Where it makes a difference is class types, C++ iterators being a prime example. Maybe the optimizer can make the two cases generate identical code, but why take the chance? I chose that example because it didn't need a full paragraph to explain, but you're right that there are probably better ones. Edit: maybe a Python example? ''.join([a, b, c]) is faster than a + b + c, but again 99% of the time you won't be using it in performance critical code. But it's a useful idiom to know.
  - jacobolus 9y ago
    From what I remember, for such small examples, a + b + c is significantly faster. (The CPython folks might have done some optimization work on this a few years back?) It’s only if you plan to concatenate a whole lot of strings that join is a clear winner.
jcelerier 9y ago
especially considering that people usually do not quote the following part of the quote : "Yet we should not pass up our opportunities in that critical 3%".
ksk 9y ago
Anything one line is prone to being misinterpreted. IMO, people who're still learning shouldn't be bombarded with a million different things, so one liners work for them. People who're experienced, realize the intent of that one liner and will easily know enough to know when it applies.

jdcarter 9y ago

> "modern computers are very complex, don't even try to understand what's happening" One thing to keep in mind is that the CPU is no longer the CPU you think it is. While the x86 instruction set used to directly control the processor, today it's just a compatibility shim. Under the covers, the CPU is converting your assembly into its own microcode and it's that microcode which is doing the real work. For example, look at some of the block diagrams in section 2 of this Intel manual: https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf https://software.intel.com/sites/default/files/managed/a4/60... Combine that with all kinds of other voodoo they've added--fancy caches, branch prediction, and so forth--and the "don't even try" maxim starts to make sense. I'd amend that to say "don't even try unless you're just curious." Personally, I think assembly is a great learning tool, e.g. for understanding how pointers work, how the stack works vs. the heap, how function calls work, and so-forth. I was exposed to Motorola 68K assembly in college and it completely changed my world--lots of C++ things I considered voodoo suddenly made total sense. But I've never used assembly in production code and probably never will.

dws 9y ago
The CPU is no longer the CPU that the CPU designers (often) think it is. A few years back someone who worked on CPUs at Intel related how his group pulling their hair out trying to characterize how a small section of code in a loop could have wildly different performance characteristics depending on the preceding instructions.
mark-r 9y ago
The Motorola 68K was nearly ideal for assembly programming. You're lucky to have learned on it.
- jdcarter 9y ago
  Oh very much so, 68K was great. Even better, at my first job we had a custom 68K-based embedded device and no source-level debugger, so you could only debug in assembly. That reinforced everything I had learned just a few years before. Our next device was MIPS-based, and MIPS was a great RISC system to learn on. I count myself very blessed.

setzer22 9y ago

> Not so long ago all I seemed to find there was people saying something like, "well, you shouldn't optimize that anyway I find this "Why would you even do that?" attitude in StackOverflow to be very irritating. And it's not just in low-level optimization questions. StackOverflow should be a place for questions and answers, not a collection of lessons on corporate best practices where curiosity and experimentation is discouraged.

jimmaswell 9y ago
I've had the same annoyance in IRC channels - getting an unhelpful lecture on the right way to do things from people who don't fully understand the use case or that "best practices" might not always be worth it or matter, especially in a small script/application
- ryandrake 9y ago
  I agree. Programming forums are full of this crap. I hate asking a pretty straightforward question online and getting that patronizing "But what are you really trying to do?" response. What I'm really trying to do is get an answer to this specific question. I'm not asking you to re-think my problem statement. Thanks for not helping.
  - eXpl0it3r 9y ago
    At the same time we're getting a lot of people with XY-problems. They think they know what the problem is and they think they know what they about have to do, while the real problem is somewhere else. If someone's intend with an asked question isn't clear, then "But what are you really trying to do?" is a valid question. It's impossible for anyone to just know what you're intentions are and whether you understand the deeper semantics of a problem. More often than not, people try to do things for the wrong reasons.
  - colomon 9y ago
    I dunno, I've been on both sides of this. I agree it's really annoying when someone waltzes around without answering my question. But I've also seen people asking questions which sounded goofy to me, and when you finally get them to tell you want they are actually trying to do, there's a much easier and more direct approach.