6 ms·
> 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
by 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 agoAlso, 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.