General...

[Delaney, Timothy]

> Hello,
> 	I love all these speed debates but if speed were our 
> only concern we would 
> all be writing in assembly for all non internet based programs...!
> 
> 	Thank you,
> 	Vincent A. Primavera

Note: I am agreeing with the spirit of Vincent's post here for those who
can't tell ;)

I wouldn't say that. There are very few assembly programmers on any platform
who can out-optimise a decently-optimising C compiler over the scope of an
entire project. Sure - they may be able to do better on small, tight parts
of the code - but the entire code base? Nah. Add in the extra time it takes
to code up and optimise, and you might as well be coding in Python ...

What's that I hear? This program is only going to be run once, but will take
a long time to run? Which will take more time in total? Coding in assembly,
testing, [recoding it right, testing, ...], finally running it once, or
coding in C, testing, [recording, testing, ...] finally running it once, or
coding in Python, testing, [recoding, testing, ...] and running it once?

Or a program that will exist for a long time, being run regularly? Will the
program *ever* need to change? (Answer to rhetorical question ... "Yes").
Who is going to do the maintenance? (Answer to rhetorical question ...
"Hopefully, not me!"). Is assembly or Python going to require the greater
effort to modify? Are many of the optimisations going to be thrown out
because the maintainer doesn't understand them? (Answer to rhetorical
question ... "Yes").

There is definitely a place for optimised assembly code. For example, I use
VirtualDub for part of the process of making VCDs. I greatly appreciate that
many of the filters are written in optimised assembly - in some cases this
as much as doubles the frame rate. The program is written in C, but specific
parts (some filters, some specific parts of the actual application) are
written in hand-optimised assembly.

This is IMO the model that should be followed for all projects, and Python
is a shining example. Write it in a high-level language, then find out what
is too slow. If possible, optimise it in the same language. If you can't see
any non-obscure way to optimise it further, look at moving that part to a
lower-level language (in Python's case, writing a module/class, etc in C).

Tim Delaney