[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Gregor Mueckl wrote:
> 1. Python is slow. I didn't do performance tests on Python before
> deciding to make this my scripting language of choice. I expected script
> code to be *way* slower than compiled code (esp. considering the
> complexity of the Python interpreter). But I had no idea how slow Python
> actually is.
Python is slow because it's a very full-featured language.
Most game's scripting requirements don't need anything like such a
sophisticated language. Also (as I explained before), I think you
actually need to use a 'byte-code' approach so that you can interpret
a little out of each of dozens of programs each frame.
I've written a real simple parser to translate a C subset into a very
simple bytecode - it's not especially fast - but it seems good enough
for my needs.
> 2. I've planned to have much more Python script code (i.e. a much lower
> level interface to the engine) than realistically possible, given that
> your figures are not too far off from what I use Python for, Steve.
> Currently I start to think about making compiled plugins, which in turn
> could act as stubs to script interpreters. So the core engine can become
> extraordinarily generic while not suffering too much speed penalty by
> loading additional compiled code instead of slower scripts for those
> parts that are too slow to remain interpreted.
Yes. If you allow '.so' plugins, they can either be pure C/C++ programs
or they can be stubs that call an interpreter to interpret Python or
whatever you need.
> Btw: Could it be that hard to write a JIT for a interpreted language
> when the script is already compiled into some bytecode (with preferably
> very few instructions)? It wouldn't have to really optimise things, but
> could avoid at least some of the overhead a bytecode interpreter needs.
> So what thit comes down to is to generate asm code junks for each of the
> instructions, which are then patched and concatenated together. I just
> don't understand why this could be so hard to do.
The main problem (as far as I'm concerned) is that you kill any hope of
portability if you generate machine-code. That's why I use a simple
byte-code. It's slower - but not unacceptably so for the relatively
simple things I expect interpreted code to do in my games.
I don't anticipate interpreting thousands of lines of code per
frame for each script - I rather expect to execute just a few
dozen bytecodes for each one.
But it all depends on what you expect your scripts to be used for.
I just want behaviours such as:
* If you hit the "use" command while pointing at the light
switch, the light turns on or off.
* If you hit the "use" command while pointing at a door, the
door will only open if you own the appropriate key.
...that kind of thing. Hence, most scripts would be less than a
dozen lines of code - but there would hundreds or perhaps thousands
of them in a typical game.
There is also the idea of using scripts for AI - but in that case,
I envision lots of high level functionality being placed into C/C++
code with the scripts just linking them together in some way that's
different for each critter in the game. These scripts would also
be just a few dozen lines long - with only a handful of those lines
being executed every frame of the game.
----------------------------- Steve Baker -------------------------------
Mail : <firstname.lastname@example.org> WorkMail: <email@example.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net