Re: Scripting

[Gregor Mueckl <GregorMueckl@gmx.de>]

Chris wrote:

> Jan Ekholm wrote:
> 
> 
>>> interpreted solution may well be "simpler" - easier to understand, or 
>>> less syntactically complex, but it is often easier for me to write 
>>> the more hairy
>>> version because it lets me do things in a few lines that would 
>>> otherwise need many.
>>
>> Ok, you may be right there. Could you give some examples of things that
>> are much simpler in a compiled language?
> 
> To start with, anything involving remotely "unsafe"* memory tricks or 
> type fiddling - complicated pointer work, interleaving types in memory 
> blocks, custom memory handling, that sort of thing: situations where the 
> type checking and controls an interpreted language imposes prevent the 
> "simpler" or more powerful solution from being usable and require 
> additional code to
> solve the problem in a different way (which gets you both ways - you end up
> doing more work in a language that is slower, so your program is slower and
> bigger than it need be..)
> 


Well, this reminds me of a piece of code I've written for the game I'm 
currently involved in. It's a C++ class to streamline variables of 
different data types (ints, longs, strings, etc) into packages suitable 
for going over a network and doing things the other way around, too. 
It's a hell of a pointer tweaking inside the code. And the worst is that 
I've given this class a Python interface to give the scripts the 
possibility to create these packages to replicate object states over the 
network. So this is basically stuff you wouldn't do in scripting 
languages, esp. since the pure C++ code really is quite small 
(*although* performance is not that big an issue in this piece of code).

Now I'm pondering whether the total design of the engine has been such a 
good idea.

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.

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.

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.


> 
> Chris

Gregor

-- 
*****************************************************
* Gregor Mueckl                 GregorMueckl@gmx.de *
*                                                   *
* The ChallengeOS project:                          *
* http://challengeos.sourceforge.net                *
*****************************************************
* Math problems?                                    *
* Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].       *
*****************************************************