Too Slow

[swestrup]

For a few years now I've been seeing essays by various pundits that computers are now fast enough and users don't need any more. I can't imagine how they get this impression. My computer is a nifty new dual-core Linux box with gobs of RAM and it regularly slows to a crawl. Just today I was writing an email and was having to wait several seconds between me hitting a key on my keyboard and the character showing up.  Now, admittedly I was also simultaneously surfing the net, re-encoding a movie, installing software, downloading software, transferring files from my machine to another on the network, and running a windows emulator, but if it can't multi-task, why bother with multiple cores?

Comments

[joenotcharles.livejournal.com]

Wow, that's a lot of parallel disk accesses. And reencoding a movie? Lots of virtual memory use too. So you end up having to page swap a lot, and the disk is busy doing 4 other things. No wonder everything slows down.

Your computer is fast enough, it's just I/O bound. Throwing more hardware at it isn't going to fix anything.

[sps.livejournal.com]

The I/O subsystem has speed, too, and it's getting less and less. Problem is that capacity is quadratic in feature density, but access rate is linear, so the bigger your hard disk, the slower it is (in a normalised sense).

We see this a lot in big installations, where the number of heads—thus performance—is going down as capacities increase.

So we need more layers in the memory hierarchy. More speed, please. This week, likely flash.

Though I notice that of the loads he mentions, only the file transfer is a read load. He must be using the wrong filesystem if the write loads are nonsequential. Come to that, bulk file transfer is also a naturally sequential load. Isn't it kind of pathetic that nobody's O/S takes advantage of this by providing hooks for sorting multifile read patterns by disk address?

As to your argument about virtual memory, I'm not entirely buying it. Disk is, as noted, better at serial access than random, so in principle, while paging may crawl, swapping can work just fine. Important memes from earlier days in computing history have been lost. True background tasks that can tolerate latencies on the scale of seconds really should be managed very differently (and perhaps written very differently).

This still applies even if we do employ flash, since flash is a inherently a serial-write medium, even if it is good (by secondary storage standards) at random read.

Finally, Sti is certainly right in his complaint: perceptible latency between keyboard or mouse and monitor is not acceptable. This is not a case of user stupidity. My diagnosis, though, is not that he needs more CPU speed, but that he needs a better scheduler: something that should be managed with a soft real time discipline is getting scheduled as if it were batch, and he's correct that as soon as the number of cores exceeds the number of users, it is possible to get this right even under pathological loads.

Things are just horribly, horribly wrong, throughout the picture.

[joenotcharles.livejournal.com]

Yes, that's my point - we don't need to throw faster hardware at users, it won't help. We need better designed hardware and software.

[joenotcharles.livejournal.com]

Although you certainly articulated what redesigns are needed much better than I could.

[sps.livejournal.com]

Mm, well, it's sort of becoming my business to do this....