http://c2.com/cgi/wiki?AsFastAsCee

My God... the cacophony of bickering voices!

Post a reply to this message

Invisible wrote:
> http://c2.com/cgi/wiki?AsFastAsCee
> 
> My God... the cacophony of bickering voices!

Einstein already said you can't go faster than c...

Post a reply to this message

Nicolas Alvarez wrote:

> Einstein already said you can't go faster than c...

Best. Quote. Ever.


25 points to Nicolas!!

Post a reply to this message

Invisible wrote:
> http://c2.com/cgi/wiki?AsFastAsCee
> 
> My God... the cacophony of bickering voices!

It isn't just the programming language, it's how you write in the 
programming language.

Simply changing the order you list your commands can make a big 
difference in speed.

On some processors counting down to zero is faster than counting up to a 
specific number.

Post a reply to this message

Tom Austin wrote:

> It isn't just the programming language, it's how you write in the 
> programming language.

It isn't just the language. It's the interpretter or compiler. It's the 
libraries. It's the runtime system (e.g., the garbage collector, the I/O 
subsystem, the concurrency implementation).

But yes, some languages make it more awkward to do things in certain 
ways, and easier to do things in certain other ways. Which may help or 
hinder performance. Also, the limitations of the language may make the 
compiler's job harder or easier.

> Simply changing the order you list your commands can make a big 
> difference in speed.
> 
> 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.

Post a reply to this message

>> 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, like if you are 
writing the row-copy code to draw part of a sprite onto the screen.

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.

Post a reply to this message

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

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

Only "inferior" if you assume they run on a machine that can access every 
single data location and process every single instruction at a constant 
speed.

As you pointed out, this certainly isn't the case and things are much more 
complex now, but that shouldn't put you off trying to optimise your code, 
you should just optimise it to work with the cache first rather than with 
the ALU.

Post a reply to this message

scott wrote:
>> 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.
> 
> Only "inferior" if you assume they run on a machine that can access 
> every single data location and process every single instruction at a 
> constant speed.

Or rather, if you assume that every possible "operation" takes the same 
amount of time - a highly useful simplification if you're trying to 
compare several different algorithms.

> As you pointed out, this certainly isn't the case and things are much 
> more complex now, but that shouldn't put you off trying to optimise your 
> code, you should just optimise it to work with the cache first rather 
> than with the ALU.

What this means is that any programming language that features automatic 
memory management is instantly many hundred times slower than a language 
using manual memory management, and there's nothing you can do about it.

I find that sad.

Post a reply to this message

Invisible escreveu:
> Nicolas Alvarez wrote:
> 
>> Einstein already said you can't go faster than c...
> 
> Best. Quote. Ever.
> 
> 
> 25 points to Nicolas!!

Indeed!  Insightful +5! :D

Post a reply to this message