11 ms·

That's a false dilemma. Higher level thinking, more expressive languages and tools don't preclude you from looking at low levels of your abstractions. Edit: L

That's a false dilemma. Higher level thinking, more expressive languages and tools don't preclude you from looking at low levels of your abstractions. Edit: Looks like we were talking past each other. I was talking about the complete article (the non-EE bits are about VM, cache, NUMA awareness, memory management for multi-threaded programs etc.) The tail end of the OP's link, links to the rest of the parts.

pacemkr 16y ago
I never said they did. In fact, I explicitly mentioned that I've explored other levels of abstraction. What I am saying is that low level thinking such as depicted in the article has little to no value to the programmer.
- terminus 16y ago
  How are you so positive about the lack of value to the programmer? What if you are programming at a low level? Performance-optimization/OS kernel/HPC inner loops/Power-sensitive code (think mobile devices)?
  - deleted 16y ago
    [deleted]
  - Groxx 16y ago
    Have you read the article? Where in there do you see any information pertaining to that kind of use? The "commodity hardware today" section is a broad, useful-content-free overview of architecture, without enough information to draw any conclusions. The "RAM types" section has nothing to do with any of your example categories. It helps how, precisely, to know which wire is energized to withdraw a bit from an SRAM circuit? pacemkr isn't saying all low level info is useless to programmers, just the article's focus.
    - terminus 16y ago
      Yes I have read the article. It is in the seven or so parts. You seem to be talking only about the first page. Part 5 deals with cache optimization. Part 6 deals with multi-threaded optimizations. Other parts deal with various layers of the memory hierarchy (VM, caches etc.)
      - Groxx 16y ago
        I am, yes. Haven't read the whole thing; I may, the later parts look significantly more useful. I, personally, only take issue with the EE-heavy portion; it only serves to obfuscate what's important with way too much (programmer-)useless info, and maybe to scare off people who could otherwise benefit from the rest of the article. I'm fairly certain that the OP of this thread views it the same way, as they mentioned: "I've enjoyed it all, but there is zero reason for a programmer to know almost anything from that page. You can make phenomenal software without ever knowing what a transistor looks like on paper;" implying just a single page (the one linked), and EE-only content.
Groxx 16y ago
But one does not need to know the behavior of atoms (if we even do) in order to whittle wood. There's a tipping point for everyone.

pacemkr 16y ago

I never said they did. In fact, I explicitly mentioned that I've explored other levels of abstraction. What I am saying is that low level thinking such as depicted in the article has little to no value to the programmer.

terminus 16y ago
How are you so positive about the lack of value to the programmer? What if you are programming at a low level? Performance-optimization/OS kernel/HPC inner loops/Power-sensitive code (think mobile devices)?
- deleted 16y ago
  [deleted]
- Groxx 16y ago
  Have you read the article? Where in there do you see any information pertaining to that kind of use? The "commodity hardware today" section is a broad, useful-content-free overview of architecture, without enough information to draw any conclusions. The "RAM types" section has nothing to do with any of your example categories. It helps how, precisely, to know which wire is energized to withdraw a bit from an SRAM circuit? pacemkr isn't saying all low level info is useless to programmers, just the article's focus.
  - terminus 16y ago
    Yes I have read the article. It is in the seven or so parts. You seem to be talking only about the first page. Part 5 deals with cache optimization. Part 6 deals with multi-threaded optimizations. Other parts deal with various layers of the memory hierarchy (VM, caches etc.)
    - Groxx 16y ago
      I am, yes. Haven't read the whole thing; I may, the later parts look significantly more useful. I, personally, only take issue with the EE-heavy portion; it only serves to obfuscate what's important with way too much (programmer-)useless info, and maybe to scare off people who could otherwise benefit from the rest of the article. I'm fairly certain that the OP of this thread views it the same way, as they mentioned: "I've enjoyed it all, but there is zero reason for a programmer to know almost anything from that page. You can make phenomenal software without ever knowing what a transistor looks like on paper;" implying just a single page (the one linked), and EE-only content.

Groxx 16y ago

But one does not need to know the behavior of atoms (if we even do) in order to whittle wood. There's a tipping point for everyone.