3 ms·

The basic premise of this article seems to be "writing good programs without heavy runtime checks is physically impossible". I'd like to ask the author, how do

by hsn915 4y ago

The basic premise of this article seems to be "writing good programs without heavy runtime checks is physically impossible". I'd like to ask the author, how does he think his computer works? The hardware is rather complex and it has to work near perfectly all the time. It should be impossible according to his premise, but it's clearning happening.

moonchild 4y ago
Hardware goes through extensive formal verification as well as testing (incidentally, it tends to be heavily instrumented, cf 'runtime checks', while it is being tested), and has its design frozen months before it goes into mass production. If you developed software the same way, you might see similar results. Most people do not develop software this way.
- uxp100 4y ago
  Yeah, formal verification of software is sort of a niche topic, formal verification of hardware is like, one of the primary tools. Shit even something like Built in Self Test, which is common in hardware, I’ve seen only rarely, and never comprehensive (I’m also not sure comprehensive BiST is the right way to think about reliability for software, it’s probably only very specific things that actually want that)
  - mhh__ 4y ago
    Hardware is also much simpler than software conceptually at least. You might think of a modern CPU as a black-box that goes out and finds (the lack of) dependencies in the instruction stream to exploit them, but this all has to be condensed into a logical circuit that is bounded in memory (registers), can be pipelined, and verified. And even then with hardware you are typically verifying things like "The pipeline never locks up entirely" or "The cache never gives back memory from the wrong physical address" basic things like that whereas these same kinds of invariants in software are rarely profitable to try and verify.
- TazeTSchnitzel 4y ago
  And despite all that effort, hardware is far from free of bugs! Lots of broken features ship and have to be disabled, or the software has to do horrible workarounds. These fixes are hidden inside CPU microcode, OS kernels, GPU drivers.
deleted 4y ago
[deleted]

by hsn915 4y ago

moonchild 4y ago

Hardware goes through extensive formal verification as well as testing (incidentally, it tends to be heavily instrumented, cf 'runtime checks', while it is being tested), and has its design frozen months before it goes into mass production. If you developed software the same way, you might see similar results. Most people do not develop software this way.

uxp100 4y ago
Yeah, formal verification of software is sort of a niche topic, formal verification of hardware is like, one of the primary tools. Shit even something like Built in Self Test, which is common in hardware, I’ve seen only rarely, and never comprehensive (I’m also not sure comprehensive BiST is the right way to think about reliability for software, it’s probably only very specific things that actually want that)
- mhh__ 4y ago
  Hardware is also much simpler than software conceptually at least. You might think of a modern CPU as a black-box that goes out and finds (the lack of) dependencies in the instruction stream to exploit them, but this all has to be condensed into a logical circuit that is bounded in memory (registers), can be pipelined, and verified. And even then with hardware you are typically verifying things like "The pipeline never locks up entirely" or "The cache never gives back memory from the wrong physical address" basic things like that whereas these same kinds of invariants in software are rarely profitable to try and verify.
TazeTSchnitzel 4y ago
And despite all that effort, hardware is far from free of bugs! Lots of broken features ship and have to be disabled, or the software has to do horrible workarounds. These fixes are hidden inside CPU microcode, OS kernels, GPU drivers.

deleted 4y ago

[deleted]