>> 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.  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 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

>> 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.

Post a reply to this message