4 ms·

>"The issue also illustrates how seemingly solid assumptions made by software and hardware engineers sometimes aren’t. Software engineers look at the currently

• raverbashing 6y ago
  This reminds me of some discussion about the evolution of games (can't find it right now, it was probably about ID Software). Computers today are literally 1000x better than PCs 30 years ago. 1000x (even more) faster, 1000x more ram, not to mention storage and other capabilities
  • netsharc 6y ago
    Huh, my 1st computer hat 640KB of RAM (does it count as a computer?), the 3rd one had either 4 or 8 MB. My current one has 16GB, so you're right, that is actually 2048 (or 4096) times more...
  • Dylan16807 6y ago
    And yet latency to RAM goes almost unchanged, which has a lot of very interesting effects.
• anyfoo 6y ago
  That's simplifying things a little. The 90s were a completely different time in computing, still somewhat pioneer when it came to "modern" operating systems in personal computing. What came before on home computers was usually tied to the actual hardware and its implementation in a very thorough way, where way more outrageous (but at the time, widely accepted) assumptions were made. For example, what memory location to write into for direct display on the screen from your application code. A few years earlier, the absolute time that a particular instruction takes. Computers became more powerful and more diverse, we added abstractions, we abolished assumptions. And still I'm pretty sure that even in Oculus (to pick up your example, I know nothing about that), there are bound to be a great deal of assumptions in the code that cease to be valid with later versions of the products.
  • anyfoo 6y ago
    By the way, it just dawned on me that preventing the division by 0 is not even solving the problem. What then, just set the delay to the biggest representable delay? But on a machine with a 1000x faster CPU, that can still be off by an order of magnitude or two. And depending on what the delay is used for, that could then cause much harder to debug problems later on. Some assumptions about reasonable ranges had to be made, just like the assumption that 32 bit was a reasonable address size back then. But a more obvious error message would have been nice (something the article mentions as well).
    • taneq 6y ago
      Yeah, the real problem is the conflation of CPU clock cycles with wall clock time and the busy-waiting.
• outworlder 6y ago
  > we would never allow such assumptions in code reviews Right. Today we have the benefit of hindsight, we know how fast processors have become. In the Win3.1 era, noone sane would have predicted this. Even Moore's Law applied to transistor counts, not processor speeds. What you should ask is: what other assumptions are you implicitly making that you are not currently aware of?
  • Dylan16807 6y ago
    > In the Win3.1 era, noone sane would have predicted this. That's a bold claim! We went from 4-8MHz 286 chips to 20-50MHz 486 chips in the decade leading up win3.1's first release. By the time we were approaching windows 95, pentiums were up to 133MHz. Those chips already had really fast branch instructions. So you're already staring down the barrel of calibration taking 15 milliseconds. It's a reasonably obvious step to consider LOOP being a cycle faster than adding and branching, which takes you all the way down to 7 milliseconds. So taking that all together, x86 clock speeeds have doubled 3-4 times in the last dozen years. A chip could come out tomorrow that takes 15 or even 7 milliseconds on the calibration loop. Your code breaks if it hits 2. I think someone sane could have predicted the problem.
  • taneq 6y ago
    Also, even into the early 2000s the majority of programmers were self-taught to varying degrees. University training, boot camps, ubiquitous internet access to reference materials etc. have vastly increased the amount of information available to a budding programmer. Back in the 90s you just hacked on something until it worked.