At 06:12 PM 9/6/2001 +0200, Paolo Molaro wrote:
>As I said in another mail, I think the stack-based approach will not
>be necessarily faster, but it will allow more optimizations down the path.
>It may well be 20 % slower in some cases when interpreted, but if it allows
>me to easily JIT it and get 400 % faster, it's a non issue.
Okay, I just did a test run, converting my sample program from interpreted
to compiled. (Hand-conversion, unfortunately, to C that went through GCC)
Went from 2.72M ops/sec to the equivalent of 22.5M ops/sec. And with -O3 on
it went to 120M ops/sec. The smaller number is more appropriate, since a
JIT/TIL version of the code won't do the sort of aggressive optimization
that GCC can do.
I'm not sure if I like those numbers (because they show we can speed things
up with a translation to native code) or dislike them (because they show
how much time the interpreter's burning). Still, they are numbers.
When I get the assembler to spit out C instead of bytecode I'll add it into
the repository.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
