[vel0city]

Yeah, I play around with retro computers all the time. Even with IO devices that are unthinkably performant compared to storage hardware actually common at the time these machines are often dog slow. Just rendering JPEGs can be really slow.

Maybe if you're in a purely text console doing purely text things 100% in memory it can feel snappy. But the moment you do anything graphical or start working on large datasets its so incredibly slow.

I still remember trying to do photo editing on a Pentium II with a massive 64MB of RAM. Or trying to get decent resolutions scans off a scanner with a Pentium III and 128MB of RAM.

[titzer]

64MB is about the size of (a big) L3 cache. Today's L3 caches have a latency of 3-12ns and throughput measured in hundreds of gigabytes per second. And yet we can't manage to get responsive UIs because of tons of crud.

[vel0city]

My modern machine running a modern OS is still way snappier while actually loading the machine and doing stuff. Sure, if I'm directly on a tty and just running vim on a small file its super fast. The same on my modern machine. Try doing a few things at once or handle some large dataset and see how well it goes.

My older computers would completely lock up when given a large task to do, often for many seconds. Scanning an image would take over the whole machine for like a minute per page! Applying a filter to an image would lock up the machine for several seconds even for a much smaller image a much simpler filter. The computer cannot even play mp3's and have a responsive word processor, if you really want to listen to music while writing a paper you better have it pass through the audio from a CD, much less think about streaming it from some remote location and have a whole encrypted TCP stream and decompression.

These days I can have lots of large tasks running at the same time and still have more responsiveness.

I have fun playing around with retro hardware and old applications, but "fast" and "responsive" are not adjectives I'd use to describe them.

[dijit]

I struggle because everything you're saying is your subjective truth, and mine differs.

Aside from the seminal discussion about text input latency from Dan Luu[0] there's very little we can do to disprove anything right now.

Back in the day asking my computer to "do" something was the thing I always dreaded, I could navigate, click around, use chat programs like IRC/ICQ and so on, and everything was fine, until I opened a program or "did" something that caused the computer to think.

Now it feels like there's no distinction between using a computer and asking it to do something heavy. The fact that I can't hear the harddisk screaming or the fan spin up (and have it be tied to something I asked the computer to do) might be related.

It becomes expectation management at some point, and nominally a "faster computer" in those days meant that those times I asked the computer to do something the computer would finish it's work quicker. Now it's much more about how responsive the machine will be... for a while, until it magically slows down over time again.

[0]: https://danluu.com/input-lag/

[vel0city]

> Back in the day asking my computer to "do" something was the thing I always dreaded, I could navigate, click around, use chat programs like IRC/ICQ and so on, and everything was fine, until I opened a program or "did" something that caused the computer to think.

This is exactly what I'm talking about. When I'm actually using my computer, its orders of magnitude faster. Things where I'd do one click and then practically have to walk away and come back to see if it worked happen in 100ms now. This is the machine being way faster and far more responsive.

Like, OK, some Apple IIe had 30ms latency on a key press compared to 50ms on a Haswell desktop with a decent refresh rate screen or 100ms on some Thinkpad from 2017, assuming these machines aren't doing anything.

But I'm not usually doing nothing when I want to press the key. I've got dozens of other things I want my computer to do. I want it listening for events on a few different chat clients. I want it to have several dozen web pages open. I want it to stream music. I want it to have several different code editors open with linters examining my code. I want it paying attention if I get new mail. I want it syncing directories from this machine to other machines and cloud storage. I want numerous background agents handling tons of different things. Any one of those tasks would cause that Apple IIe to crawl instantly and it doesn't even have the memory to render a tiny corner of my screen.

The computer is orders of magnitude "faster", in that it is doing many times as much work much faster even when it's seemingly just sitting there. Because that's what we expect from our computers these days.

Tell me how fast a button press is when you're on a video call on your Apple IIe while having a code linter run while driving a 4K panel and multiple virtual desktops. How's its Unicode support?

[Dylan16807]

But I can see that all the background stuff is using less than one core. That is not an excuse for bad foreground performance.

The stuff that used to be slow involved hard drive access, but today even when programs don't need to touch the disk they often manage to rack up significant delays. Not to mention how SSDs have 100x less latency than hard drives.

And if unicode support is causing serious delays when I'm only using one block of simple-rendering characters, then the library was designed badly.

[kristianp]

The newish windows photo viewer in Win 10 is painfully slow and it renders a lower res preview first, but then the photo seems to move when the full resolution is shown. The photo viewer in windows 7 would prerender the next photo so the transition to the next one would be instant. The is for 24 megapixel photos, maybe 4mb jpegs.

So the quality has gone backwards in the process of rewriting the app into the touch friendly style. A lot of core windows apps are like that.

Note that the windows file system is much slower than the linux etx4, I don't know about Mac filesystems.