Bartc said:
For pure integer code, I always found it difficult to break the 10x slower
barrier compared with, say, C (although I'm currently working on that!).
But, I had decided originally that when the interpreted language was used
properly, it should only be between 1x to 2x as slow as a compiled
equivalent, and in most cases this was achieved, while making development a
delight because it was so easy.
Even forgetting library calls, an interpreted language doing high level
things (working with strings, entire arrays, etc) can compare well with pure
C.
Interpreted languages doing high level things are most likely
translating one or two language primitives into "call a big chunk of
compiled code", and when you're doing that the return on investment for
spending extra time optimizing the compiled code goes way up, so it
usually ends up faster than writing the code directly in C. (Unless
you do something dumb like using an expensive language primitive to do
an operation that can be done cheaply without it.)
Compiling to native code wins easily when you can't reduce code that
does nontrivial things to a short sequence of language primitives,
though, since the interpreter has to stop and look up what to do again
after every interpreted-language instruction, and compiled code can
skip that part.
I work with people who like to write everything in Matlab.
For what it's good at (pretty much any easy-to-describe numerical
computation), I won't even bother trying to make my C run as fast as
the Matlab runtime. I occasionally convert Matlab code to something we
can call from a C program without having to ship with the Matlab
runtime, but if it's performance-critical I'll tell them to just ship
the Matlab code.
But occasionally they'll come to me with code that loops over a big
array doing something that there aren't Matlab primitives to do
array-at-a-time and that's way too slow, and when that happens I can
easily get a factor of five or ten speedup even before I ask the
compiler to optimize it (i.e. working with one hand tied behind my
back), just by writing C code to do the same thing.
Good interpreted languages[1] make it easy to write compiled-to-native
code and call it from the interpreted scripts, which essentially lets
the user-programmer write their own primitives. Though making it as
easy to optimize as aggressively as they do for the builtin ones is a
little bit harder, and well beyond the scope of what the people who
sell the interpreted languages are trying to do.
dave
[1] Matlab meets this criterion for "good" (it's the only one I've had
reason to find out about).
--
Dave Vandervies dj3vande at eskimo dot com
Have you checked under your desk for stray sixes?
So *that's* where the beast is!
--Normal L. DeForest and Stuart Lamble in the scary devil monastery