>>> You cannot just take a mathematical paper and expect it to work as 
>>> described on a computer, you never have been able to.
>>
>> Back in the days of the 8-bit home computer, memory access really was 
>> a constant-time operation that always took 1 clock cycle.
> 
> 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.

> Also some operations were free (eg shifting 
> when adding, other obscure things like that), a general mathematical 
> paper won't take that into account when telling you the "best" algorithm 
> for a task.

Sure. But if one algorithm takes 5,000 operations (some of which might 
be free) and another takes 72,000,000,000 operations, which one is 
fastest? On the computers of old, the answer was self-evident. Today, it 
might well be that the latter is actually faster.

>>> Sure, but it's always been like that and always will, there's nothing 
>>> you can do about it.
>>
>> It wasn't always like that -
> 
> So your early 8bit computer could write to the tape at the same speed as 
> RAM? :-O

More like in the early days, if it didn't fit in RAM, you just couldn't 
do it at all. 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).

>>> If your language/compiler is clever enough to switch around the order 
>>> and storage of your code, then it should be clever enough to optimise 
>>> for the memory structure of the machine.
>>
>> Sure. But if it isn't, you can't do anything about it. You can't 
>> rewrite the compiler, after all...
> 
> If your compiler changes the order that data is stored, or the order you 
> access it, but doesn't take into account how this affects performance, 
> then IMO it's broken.  Use a different compiler that either leaves the 
> order alone (so you can optimise it yourself) or optmises it for you.

How about if the order just plain isn't defined in the first place? Or 
if the runtime system is storing auxhilery data which you don't know about?

Post a reply to this message