Orchid XP v8 wrote:
> Kevin Wampler wrote:
>> Orchid XP v8 wrote:
>>> OK, cool. So basically there is no way I can tell whether 
>>> implementing an algorithm one way or the other will yield the best 
>>> speed. Yay, me. :-/
>>
>> It won't tell you everything about the speed of the final program, but 
>> I can't imagine it'd be hard to write some test programs and then time 
>> them to determine some of these answers for yourself.
> 
> I guess I'm still used to the Old Days of computing, when the speed of 
> the CPU was the primary bottleneck. Of course, these days the memory 
> subsystem is the primary bottleneck - to the point where algorithms 
> which are "less efficient" on paper can actually run faster in reality 
> if they have superior cache behaviour.
> 
> Obviously, cache behaviour is something I have absolutely no control 
> over, so there's no point worrying about it.
> 


Depends on what language you are using.

Even today some programs are written to use only internal registers - 
only using external memory when absolutely necessary.

Also, depending on what processing unit you are using it could be faster 
to count down to zero than up to a given number - based on the machine 
instructions available and the time cost of each instruction.


When you get into high level languages you are going to lose some 
efficiency in execution because the focus starts towards ease of actual 
programming vs execution efficiency.

You get to a point where the program just runs and the compiler gives 
little care to optimizing the execution speed.  It's easier to program, 
but at a cost.



Tom

Post a reply to this message