4 ms·

It's clear from Fowler's discussion of "mechanical sympathy" that he didn't understand the memory hierarchy. I found it pretty shocking that someone in his posi

by vilya 15y ago

It's clear from Fowler's discussion of "mechanical sympathy" that he didn't understand the memory hierarchy. I found it pretty shocking that someone in his position could not know this stuff. He really needs to read Ulrich Drepper's "What every programmer should know about memory" (http://www.akkadia.org/drepper/cpumemory.pdf http://www.akkadia.org/drepper/cpumemory.pdf). It's such a fundamental topic that everyone ought to at least know the basics of it. People architecting large systems, like Fowler, have a special responsibility to know these things: if they aren't taken into consideration in the system design, it's easy to dig a performance hole too deep to climb out of.

koevet 15y ago
Can you be more specific?
- vilya 15y ago
  About the performance issues? Well I work on software that does image processing at the moment & we've chosen to represent images as separate channels (i.e, all the red values, then all the green values, then all the blue values, etc). If we had interleaved the channels instead, many common operations that only need to look at one channel - or just one at a time - would be a lot slower. When data is loaded into the cache, it's loaded in chunks called cache lines. These are usually 64 or 128 bytes long, depending on your CPU. So assuming a 64 byte cache line, if you ask for the value at address 4 then it'll load in all the values in addresses 0-63. If you then ask for the value at address 8, it'll already be cached & therefore quick to access; but if you ask for the value at address 64, it'll have to fill another cache line first - a cache miss. So back to the images, say we're just looking at the alpha channel of an RGBA image. With separate channels we get 16 alpha values in each cache line (each channel is a float, so 4 bytes). If the channels were interleaved then we'd only get 4 alpha values in each cache line, so the CPU will have to fill 4 times as many cache lines. Because so much of our code deals with images (and not just ours - our clients too), if we'd chosen an interleaved channel representation and were now finding that too slow, we'd be pretty stuck. So it's really important to consider these issues up front, but of course you can't if you don't know at least a little bit about how the hardware works. Hopefully that explains it a bit better?
chrisjsmithuk 15y ago
The high level architectural patterns he usually deals with will live decades longer than the memory and cache heirarchy problems we have at the moment, so I don't think he's particularly concerned at that level.
jasonwatkinspdx 15y ago
He states pretty explicitly that he doesn't feel he has an intuitive understanding of hardware's performance quirks right in that section. Why should you then be surprised?
- vilya 15y ago
  Because this is a guy who's supposed to be an authority on software engineering & reading something like that makes me wonder how on earth he ever came to be an authority. It's a bit like someone convincing you they're a racing driver then admitting they're not really sure what the clutch does. (Yes that's hyperbole, but still...)
  - jasonwatkinspdx 15y ago
    To abuse your analogy there are many fast drivers that have little to know mechanical knowledge. You seem to be under the impression that to be an authority one must have comprehensive and detailed knowledge, particularly in areas you care about. I believe this is rarely the case. It's far more important to understand the essential. The key to being a good leader is not to know everything better than everyone, but to understand how to help everyone contribute their best, then get out of the way.
    - vilya 15y ago
      > You seem to be under the impression that to be an authority one must have comprehensive and detailed knowledge, particularly in areas you care about. Detailed and comprehensive knowledge is exactly what I expect from an authority on a subject. If they don't have it, then on what basis are they considered an authority? It sounds to me - and I apologise if I've misunderstood - like you are arguing that a software architect doesn't need to understand the performance impact of their designs to be considered an authority on their subject? If so, then I respectfully disagree. It's possible to be a (bad) software architect without understanding that stuff, but I expect better from people who are supposed to be experts in the field. > The key to being a good leader is not to know everything better than everyone, but to understand how to help everyone contribute their best, then get out of the way. That's all very well but we're not talking about being a leader, we're talking about being an expert.

by vilya 15y ago

koevet 15y ago

Can you be more specific?

vilya 15y ago
About the performance issues? Well I work on software that does image processing at the moment & we've chosen to represent images as separate channels (i.e, all the red values, then all the green values, then all the blue values, etc). If we had interleaved the channels instead, many common operations that only need to look at one channel - or just one at a time - would be a lot slower. When data is loaded into the cache, it's loaded in chunks called cache lines. These are usually 64 or 128 bytes long, depending on your CPU. So assuming a 64 byte cache line, if you ask for the value at address 4 then it'll load in all the values in addresses 0-63. If you then ask for the value at address 8, it'll already be cached & therefore quick to access; but if you ask for the value at address 64, it'll have to fill another cache line first - a cache miss. So back to the images, say we're just looking at the alpha channel of an RGBA image. With separate channels we get 16 alpha values in each cache line (each channel is a float, so 4 bytes). If the channels were interleaved then we'd only get 4 alpha values in each cache line, so the CPU will have to fill 4 times as many cache lines. Because so much of our code deals with images (and not just ours - our clients too), if we'd chosen an interleaved channel representation and were now finding that too slow, we'd be pretty stuck. So it's really important to consider these issues up front, but of course you can't if you don't know at least a little bit about how the hardware works. Hopefully that explains it a bit better?

chrisjsmithuk 15y ago

The high level architectural patterns he usually deals with will live decades longer than the memory and cache heirarchy problems we have at the moment, so I don't think he's particularly concerned at that level.

jasonwatkinspdx 15y ago

He states pretty explicitly that he doesn't feel he has an intuitive understanding of hardware's performance quirks right in that section. Why should you then be surprised?

vilya 15y ago
Because this is a guy who's supposed to be an authority on software engineering & reading something like that makes me wonder how on earth he ever came to be an authority. It's a bit like someone convincing you they're a racing driver then admitting they're not really sure what the clutch does. (Yes that's hyperbole, but still...)
- jasonwatkinspdx 15y ago
  To abuse your analogy there are many fast drivers that have little to know mechanical knowledge. You seem to be under the impression that to be an authority one must have comprehensive and detailed knowledge, particularly in areas you care about. I believe this is rarely the case. It's far more important to understand the essential. The key to being a good leader is not to know everything better than everyone, but to understand how to help everyone contribute their best, then get out of the way.
  - vilya 15y ago
    > You seem to be under the impression that to be an authority one must have comprehensive and detailed knowledge, particularly in areas you care about. Detailed and comprehensive knowledge is exactly what I expect from an authority on a subject. If they don't have it, then on what basis are they considered an authority? It sounds to me - and I apologise if I've misunderstood - like you are arguing that a software architect doesn't need to understand the performance impact of their designs to be considered an authority on their subject? If so, then I respectfully disagree. It's possible to be a (bad) software architect without understanding that stuff, but I expect better from people who are supposed to be experts in the field. > The key to being a good leader is not to know everything better than everyone, but to understand how to help everyone contribute their best, then get out of the way. That's all very well but we're not talking about being a leader, we're talking about being an expert.