Re: Writing games in interpreted languages

[Steve Baker <sjbaker1@airmail.net>]

Christian Reiniger wrote:
> 
> Steve Baker wrote:
> 
> >> I disagree. The fact that Perl (or Python, Scheme, etc) code is
> >> interpreted in software rather than being executed on an actual processor
> >> just means that this particular piece of code will need a few more
> >> processor cycles to be executed.
> >
> >A *few* more?!?  Try 50 times slower than C or C++ !!  (For python at least).
> 
> Perl isn't that bad. In "The Practice of Programming" there's a "benchmark"
> of functionally identical Markov programs (random but more or less senseful
> text generation) in different languages.
> Plain C is clearly first (0.30/0.36 sec, 150 LOC)
> Perl is second (1.0/1.8 sec, 18 LOC)
> C++/STL is third (1.5/1.7 sec, 70 LOC)

Right there you can tell that this is a bogus test.

A good C++ programmer would have realised some horrible
inefficiency in this implementation and created code that
would essentially have been written in C (if that's what
it takes to do this right).  That would produce C++ timings
essentially identical to the C timings - so, let's put aside
the C++ test and put it down to use of STL - which is a pretty
generalized toolkit.

If (as you suggest), the test's problem is kinda Perl-oriented,
then we should ignore that result also. 

Awk is specifically a text processing system - so it might be
running well for the same reason as Perl.

That leaves the Java benchmark.  Since Java is pretty much like
C++ - but doesn't let you fall back to simpler C-like paradigms
when you need to, it's a more reasonable benchmark.

It runs 9 seconds versus 0.3 - so it's 30 times slower than C.

Well, that's better than the couple of a'hoc test results that
I got playing with Python - and maybe Python is somehow worse
than Java - and maybe my tests were not 'realistic' tests.

However, I don't believe anyone should go away with the impression
that you're only going to see a factor of 2 or 5 difference.  Just
think about what an interpreter has to do for each interpretation
step and you have to see that getting a factor of only (say)
five degradation is not going to be possible for 'general'
algorithms written entirely in the language.

You can always invent benchmarks that look better than that by
doing stuff like heavy string handling - but then you are essentially
racing the interpreters internal string routines against the C
standard library string routines - and that tells you very little
about the likely performance for game routines.

Don't get me wrong though.  There is a place for interpretive
languages in the upper levels of game code - and in fact the
PrettyPoly project I'm working on right now is heavily into
Python.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)