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 architecture. 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 at! (see Intel's compiler for an example of this sort of thing done automatically). Cheers, Paul. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Particle Physics (Theory & Experimental) Groups Paul Millar Department of Physics and Astronomy [EMAIL PROTECTED] University of Glasgow [EMAIL PROTECTED] 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 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- _______________________________________________ Scottish mailing list [EMAIL PROTECTED] http://mailman.lug.org.uk/mailman/listinfo/scottish
