Am 14.06.2010 17:45, schrieb Invisible:

>> Sure, but just as an example, what's the fastest way to sort a 10 KB
>> array when you have 16 KB or RAM? The mathematically efficient way
>> won't necessarily be the quickest if you need to read/write to
>> tape/disc rather than just using RAM.
>
> Then you use a specialised external-sort. More to the point, you *know*
> that you're going to need an external-sort. Your program doesn't just
> magically run 500x slower than you'd expected.

Which is just the point to learn from this: You should (ideally) know 
that the very same is true for today's computers, so that you know where 
such "magical" slowdowns come from, and what can be done against it.

> More like in the early days, if it didn't fit in RAM, you just couldn't
> do it at all.

Nonsense. Datacenters have been using slow memory, such as magnetic 
tapes, for ages. "If it all fits in RAM, then congratulations!" would 
have been closer to the mark back then I guess.

 > Today if it doesn't fit in RAM, the OS makes the computer
> pretend it has more RAM than it does (with the *minor issue* of a vast
> slowdown and halving the life of your harddrive).

I'd rather put it this way: Today, if it doesn't fit in RAM, the OS 
helps you "juggling" the memory chunks to work on. (And if it doesn't 
fit in L1 or L2 cache, the CPU provides essentially the same service.) 
Which makes life much easier in a world where you don't know how much 
RAM you'll have when programming the software. (Back then, you /did/ 
know the specs of the one machine you wrote your programs for.) Plus, it 
allows much easier and faster (and therefore more economical) design of 
software where runtime performance doesn't matter that much.

(As for harddrive life, I guess that depends on your harddrive.)

Post a reply to this message