scott wrote:
>>> On some processors counting down to zero is faster than counting up 
>>> to a specific number.
>>
>> If you're comparing JIT-compiled Java to purely interpretted Lisp, I 
>> guarantee you it makes no measurable difference. The overhead of 
>> everything else outweighs it manytimes over.
> 
> Sure, but there are circumstances when it is measureable.

I'm sure there are. I'm saying that in very high-level languages (e.g., 
Perl, VB, etc.) there are much bigger influences to worry about fist.

> Actually I remember on my 32bit ARM CPU, if you want to copy a large 
> number of bytes from a word (32-bit) aligned address to a 
> non-word-aligned address there were two ways to do it.  The first was to 
> just use the load-byte and store-byte commands, but a way faster method 
> was to load and store words at a time with some clever bit shifting and 
> masking.  Even though the code looked uglier and longer, it was much 
> faster.  Similarly, counting down to zero saved one clock cycle per 
> loop, and when your loop is only a few clock cycles and your game is 
> limited by the speed of drawing sprites on the screen it makes a big 
> difference.

Now, see, as I understand it, computer technology has now reached the 
point were saving a few cycles makes *no difference* at all, and the 
_only_ thing that matters is cache hit ratios.

If you use a faster addressing mode, maybe your program will complete a 
few microseconds faster. If you have a pipeline stall, your program will 
halt for a dozen cycles, and if there's a miss in the L2 cache, the CPU 
will basically shut down and do nothing for several thousand cycles.

It's got so bad that theoretically "inferior" algorithms can actually be 
faster due to cache behaviour, even though they take "more operations" 
to do.

Personally, I find that sad...

Post a reply to this message