![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
http://c2.com/cgi/wiki?AsFastAsCee
My God... the cacophony of bickering voices!
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |