4 ms·

> My reasoning here is that understanding a computer at this level really helps understand programming, and perhaps more importantly the translation between wha

by qayxc 6y ago

> My reasoning here is that understanding a computer at this level really helps understand programming, and perhaps more importantly the translation between what you want a program to do and how the computer would actually do it. This logic would've worked in 1985 and maybe, just maybe until 1993. Modern CPUs cannot be programmed at the level that TTL provides. The µArch itself has long since become an abstraction in and of itself. Depending on the instruction set, there's often no way to predict beforehand how certain data- and code paths will behave. That's why modern compilers use optimisation techniques such as profile guided optimisation. If you think that certain µArchs are easier to understand in that regard than others (e.g. x86 vs ARM), think again. There's inaccessible embedded hardware [0], and SoCs hidden behind proprietary RTOSes [1] that prevent direct access. Detailed knowledge about building the hardware is therefore only of very limited use in real-world applications; unless you plan to become a firmware-, driver-, or compiler developer. Even in the embedded world, data sheets can be deceiving and ultimately knowing your (compiler-) toolchain and knowing how to test the behaviour in practise is far more valuable. General knowledge should be required, yes, but going so far as to build an actual computer "from scratch" isn't as helpful as it might seem. [0] https://news.ycombinator.com/item?id=25801500 https://news.ycombinator.com/item?id=25801500 [1] https://en.wikipedia.org/wiki/VideoCore https://en.wikipedia.org/wiki/VideoCore

TheOtherHobbes 6y ago
Agreed. The distance between CS abstractions has widened to the point where the lower level abstractions are only relevant to the people who build them. There's a close and obvious relationship between C statements and the PDP-11 instruction set. And at least one PDP-11 series processor was implemented with gate-level logic with no microcoding. So anyone with time to spare could copy that. It's not a trivial job, and it's probably more time than it's worth. But it's not unimaginably hard either. There's no obvious relationship at all between (say) Python and the gate-level internals of any mainstream modern CPU. There are at least four (five? six?) levels of abstractions between them. It's useful to build a generic gate-level processor to have some notional idea of what a computer is. And of course it's essential if you go into processor design. But µArch details are a graduate-level topic and not something most developers need to worry about.
mulmen 6y ago
The suggestion is not to build the computer. It is to learn how to build a computer. The software manufacturing industry could do with some more silicon sympathy. See: Wirth's Law. https://en.wikipedia.org/wiki/Wirth's_law https://en.wikipedia.org/wiki/Wirth's_law
- qayxc 6y ago
  > The software manufacturing industry could do with some more silicon sympathy. These are still orthogonal concepts. First of all, it's all about cost: if the operational costs of running a piece software over the lifetime of said software are significantly lower than the cost of optimisation, there's nothing to be gained from doing the latter. Developer time is more expensive than a faster CPU, additional RAM or slightly higher power usage. Back in the day, the iron was expensive and developer time was cheap. Today it's the other way around, so saving on development time is more important than optimising for specific hardware. Hardware-level optimisation becomes especially bogus if your deployment target is data centres - you often don't even know the deployment target beforehand (could be an ARM CPU, could be an x86 CPU). With many modern SoCs (see the M1), it's even impossible to optimise at that level, since you don't even get the required hardware specs and simply using Apple's libraries will get the best results. So my argument still stands: there's litte benefit in general from going into such detail. Feel free to disagree, but developments like the Go language, SoCs, and GPGPU compute seem to point another direction. > It is to learn how to build a computer. And how does that translate to actual hardware then? Very poorly still. The fact is that unless you work with certain embedded systems, you never get close enough to the hardware to benefit from this. This is time better spent on learning how to use your tools and to learn how to benchmark and optimise based on algorithms and data structures instead, because that's where the inefficiencies start. Besides, most programming languages are so far removed from the hardware, that there's absolutely nothing you can do to optimise (JS, Python, Go, Java, C#, Haskell, LISP, etc.).
  - trasz 6y ago
    Developer time is expensive, sure. But poorly performing software, while perhaps sparing the original developer’s time, wastes time for users and other developers.
oivey 6y ago
It’s pretty useful to know some low level computer engineering if you’re writing high performance software. Having some understanding as to how memory, cache, and threads work for your target platform is pretty important in a lot of applications. That sort of knowledge gives you a big head start when learning to program GPUs, too.
- williamdclt 6y ago
  The large majority of us (easily above 90%) do not write high performance software, or program GPUs. I'm not saying it's useless to understand what's happening low-level, but pretending every should be required to have this knowledge is like asking all SE to be able to do deep learning, it's just not relevant for most people.
  - oivey 6y ago
    Low level programming isn’t like some disused area of mathematics that was popular in the early 20th century; it underpins everything we do. Your OS, your network stack, your graphical desktop, your browser, probably your favorite language’s interpreter, all depend on writing high performance code. At any point you’re probably a single step away from some C. Languages like Python made it much easier to program but didn’t put as much thought into performance. I think the future of computing will be in languages that manage to be pleasant to write like Python while still exploiting low level hardware features. Rust, which is like C++ that doesn’t suck, and Julia, which is like Python with cleaned up semantics to allow easier compilation, come to mind. The economics of a few people developing high performance languages that everyone can use just makes too much sense. More cloud computing may be cheaper than more devs, but it still isn’t cheap in the absolute sense.
    - williamdclt 6y ago
      I agree with your comment, I don't think we say different things. In particular, cherry-picking something you said: > The economics of a few people developing high performance languages that everyone can use just makes too much sense I agree: high performance is the job of a _few_ people. It doesn't hurt to know basics for it for everybody else, but even then... that's just one area out of many a dev could dive into. Maybe security or virtualisation or OS programming or whatever would be just as useful or more. My point is that we can't pick a random subfield of software engineering and say "everybody should be skilled at that"

by qayxc 6y ago

TheOtherHobbes 6y ago

Agreed. The distance between CS abstractions has widened to the point where the lower level abstractions are only relevant to the people who build them. There's a close and obvious relationship between C statements and the PDP-11 instruction set. And at least one PDP-11 series processor was implemented with gate-level logic with no microcoding. So anyone with time to spare could copy that. It's not a trivial job, and it's probably more time than it's worth. But it's not unimaginably hard either. There's no obvious relationship at all between (say) Python and the gate-level internals of any mainstream modern CPU. There are at least four (five? six?) levels of abstractions between them. It's useful to build a generic gate-level processor to have some notional idea of what a computer is. And of course it's essential if you go into processor design. But µArch details are a graduate-level topic and not something most developers need to worry about.

mulmen 6y ago

The suggestion is not to build the computer. It is to learn how to build a computer. The software manufacturing industry could do with some more silicon sympathy. See: Wirth's Law. https://en.wikipedia.org/wiki/Wirth's_law https://en.wikipedia.org/wiki/Wirth's_law

qayxc 6y ago
> The software manufacturing industry could do with some more silicon sympathy. These are still orthogonal concepts. First of all, it's all about cost: if the operational costs of running a piece software over the lifetime of said software are significantly lower than the cost of optimisation, there's nothing to be gained from doing the latter. Developer time is more expensive than a faster CPU, additional RAM or slightly higher power usage. Back in the day, the iron was expensive and developer time was cheap. Today it's the other way around, so saving on development time is more important than optimising for specific hardware. Hardware-level optimisation becomes especially bogus if your deployment target is data centres - you often don't even know the deployment target beforehand (could be an ARM CPU, could be an x86 CPU). With many modern SoCs (see the M1), it's even impossible to optimise at that level, since you don't even get the required hardware specs and simply using Apple's libraries will get the best results. So my argument still stands: there's litte benefit in general from going into such detail. Feel free to disagree, but developments like the Go language, SoCs, and GPGPU compute seem to point another direction. > It is to learn how to build a computer. And how does that translate to actual hardware then? Very poorly still. The fact is that unless you work with certain embedded systems, you never get close enough to the hardware to benefit from this. This is time better spent on learning how to use your tools and to learn how to benchmark and optimise based on algorithms and data structures instead, because that's where the inefficiencies start. Besides, most programming languages are so far removed from the hardware, that there's absolutely nothing you can do to optimise (JS, Python, Go, Java, C#, Haskell, LISP, etc.).
- trasz 6y ago
  Developer time is expensive, sure. But poorly performing software, while perhaps sparing the original developer’s time, wastes time for users and other developers.

oivey 6y ago

It’s pretty useful to know some low level computer engineering if you’re writing high performance software. Having some understanding as to how memory, cache, and threads work for your target platform is pretty important in a lot of applications. That sort of knowledge gives you a big head start when learning to program GPUs, too.

williamdclt 6y ago
The large majority of us (easily above 90%) do not write high performance software, or program GPUs. I'm not saying it's useless to understand what's happening low-level, but pretending every should be required to have this knowledge is like asking all SE to be able to do deep learning, it's just not relevant for most people.
- oivey 6y ago
  Low level programming isn’t like some disused area of mathematics that was popular in the early 20th century; it underpins everything we do. Your OS, your network stack, your graphical desktop, your browser, probably your favorite language’s interpreter, all depend on writing high performance code. At any point you’re probably a single step away from some C. Languages like Python made it much easier to program but didn’t put as much thought into performance. I think the future of computing will be in languages that manage to be pleasant to write like Python while still exploiting low level hardware features. Rust, which is like C++ that doesn’t suck, and Julia, which is like Python with cleaned up semantics to allow easier compilation, come to mind. The economics of a few people developing high performance languages that everyone can use just makes too much sense. More cloud computing may be cheaper than more devs, but it still isn’t cheap in the absolute sense.
  - williamdclt 6y ago
    I agree with your comment, I don't think we say different things. In particular, cherry-picking something you said: > The economics of a few people developing high performance languages that everyone can use just makes too much sense I agree: high performance is the job of a _few_ people. It doesn't hurt to know basics for it for everybody else, but even then... that's just one area out of many a dev could dive into. Maybe security or virtualisation or OS programming or whatever would be just as useful or more. My point is that we can't pick a random subfield of software engineering and say "everybody should be skilled at that"