4 ms·
> You just don't remember 20 years ago. The modern OSs at the time were sluggish too, as they were pushing the limits of their hardware. I would venture to gue
by justin66 5y ago
> You just don't remember 20 years ago. The modern OSs at the time were sluggish too, as they were pushing the limits of their hardware.
I would venture to guess that you will not find anyone whose experience with Windows 2000 included any slowness comparable to what we see today, if they got it on a new PC of the time or if they installed it themselves on a newish PC of the time. It’s tempting to blame input and display latency on the increased amount of work an OS does versus wherever we happen to sit on the curve of Moore’s law, but that discounts the fact that the values, priorities, and abilities of the engineers and designers involved in OS development might have changed.
This is the sort of thing that can be tested and measured. I’d wager if you benchmark a good-spec twenty year old PC and any Windows 11 PC on common user tasks in the UI, the twenty year old machine will be faster while using a higher percentage of its CPU time performing the simple tasks you’re testing against. It’s more or less impossible to use a significant fraction of the CPU’s time dragging the mouse pointer around and opening and closing menus, or even opening and closing normal user apps, on a modern desktop PC, as you might very well see on the old one, so one might want to contemplate why the new PC’s UI has so much latency built in compared to the old one…
(I remember 20 years ago)
- eloisius 5y agohttps://danluu.com/input-lag/ https://danluu.com/input-lag/
- justin66 5y agoThat’s extremely good stuff, but hopefully it’s obvious from my previous comment that keypress latency isn’t really what I was talking about testing. With some good software and a modern USB 3 keyboard you can engineer a program that on a windows 11 pc puts a character on the screen at some respectable time multiple (sigh) of an Apple II, but how much unavoidable UI and other OS slowness would a user have to navigate through just to start up such a program? (and do we really think hardware performance is the limiting factor there, or poor software engineering and design?)
- actionfromafar 5y agoI tested NT 3 something on a DEC workstation on Alpha CPU, at a trade show in the early 90s. Already then, it didn't seem like dragging things around would eat a significant amount of CPU. I started a bunch of AVI videos playing at the same time, while dragging windows around, and everything was smooth.
- justin66 5y agoThe interesting question is: if opening up and playing all those same videos in a similar fashion is a less smooth experience today with windows and its built in stuff, on a PC that’s a thousand times faster, why? Watching videos isn’t a great test of what we’re talking about, but the “everything else” involved in getting to them, opening them and navigating them might be revelatory?
- tinus_hn 5y agoWatching SD videos and dragging them around on the 1024x768 screen. People forget that a modern computer has such a large screen the frame buffer would barely fit in the memory of these old computers. It’s a lot of work to manipulate all these pixels and it requires much larger assets as well.
- rjsw 5y agoThe Alpha may have only been using 8 bits per pixel, it all makes a difference.
- goosedragons 5y agoRight but a 4K monitor only has about 10.5 times more pixels than a 1024x768 one. In 2000 a high end GPU might have had 32MB VRAM and these days even Intel's worst stuff has access to over 1GB over 30 times as much and even low-end gaming GPUs having 4GB with higher end stuff with 8 or 12GB. Plus the GPUs themselves have gotten much faster and OSs have moved more GUI rendering from the CPU to the GPU.
- justin66 5y ago
- roywiggins 5y agoReminds me of this demonstration of a single era-appropriate PC driving several Premiere instances at the same time on their own desktops: https://youtu.be/v8tjA8VyfvU?t=3315 https://youtu.be/v8tjA8VyfvU?t=3315