[Scottish] Computing Power debate

Paul Millar scottish at mailman.lug.org.uk
Tue Oct 1 11:04:00 2002

On Fri, 27 Sep 2002, Aidan Skinner wrote:
> Three things:
> 1. C is /still/ the most used programming language, for god only knows
> what reason

Hmmm, that certainly used to be true, but I guess its probably not
anymore.  Hasn't C++ overtaken it (as in Visual C++ for example), or
(shudder) VBA?

As for why C is popular: it does the job, its *largely* portable and, if
you abstract out hardware differences, it can be made portable. What more
do you _need_?

> and you don't get muhch lower level than semi-portable asm.

Pointing out the obvious, but asm isn't portable, really. Only on the same 

I don't want to rave about C, but it does let you do all those
bit-twiddling things without having to resort to assembler. If compilers 
were decent, then they should be able to produce better code than 
"hand crafted" assembler.

> 2. High level languages like python can, in theory, be much quicker
> than low level languages: http://psyco.sourceforge.net/introduction.html

Hmmm yes. Another example is FFTW.

But I'd say this is more because the language is interpreted rather than
it being high or low level. If a language is compiled, then your stuffed:  
the compiler produces what it thinks of as the best code but it wont take 
into account any hot-spots.

Having said that, there is a correlation: you don't tend to get low-level
interpreted languages (at least not serious ones;)

> 3. Language choice is totally epsilon compared to algorithim choice,
> the difference between C and Python is prolly in the order of 10% at
> worst, the difference between a skip list and a linked list is so much
> more.

Yep. very much so.  BTW, I hadn't heard of skip lists before. After a 
little Googling, I found an implementation that looked rather like a 
binary tree.  Are the two roughly the same?

> > Maybe another problem is that compiler optimisations aren't being fully
> > exploited so that the software can run on any x86 box.
> > I wonder what a 686 optimised version of Word would be like, for example.
> again, compiler optimisation won't get you anything like the speedup
> that proper algorithim choice will.

Yes, but "proper algorithms" will depend on the exact architecture too.

For example, if your problem involves lots of floating-point operations,
such that you've always got to do the same operation on at least two of
them, you can use 3DNow-like SIMD parallel processing and work twice as
fast. If your program is floating-point-bound, that isn't to be sniffed

(see Intel's compiler for an example of this sort of thing done



-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Particle Physics (Theory & Experimental) Groups                   Paul Millar 
Department of Physics and Astronomy                     paulm@astro.gla.ac.uk
University of Glasgow                                 paulm@physics.gla.ac.uk
Glasgow, G12 8QQ, Scotland             http://www.astro.gla.ac.uk/users/paulm 
+44 (0)141 330 4717        A54C A9FC 6A77 1664 2E4E  90E3 FFD2 704B BF0F 03E9
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --