[Python-Dev] Re: native code compiler? (or, OCaml vs. Python)

[Dan Sugalski]

At 9:12 AM +0100 1/31/03, Fredrik Lundh wrote:
>Dan Sugalski wrote:
>
>>  Ignoring parrot, I'll point you at some of the Scheme and Smalltalk
>>  setups.  (And you'd be hard-pressed to find something to beat smalltalk
>>  for runtime dynamism)
>
>Not on python-dev.

The original topic was native-code compilers, and it was put forth 
that writing one for a dynamic language was either very hard or 
impossble, and if you did there wasn't much win. The counterexamples 
of the Scheme and Smalltalk compilers are relevant--both languages 
are more dynamic at runtime, and both languages have native compilers 
that provide significant speed benefits, and both languages have 
implementations with relatively little man-time and brainpower that 
provided significant speed benefits without semantic changes.

Unless I'm misreading you, and you're positing that python's more 
dynamic at runtime than smalltalk, but I presume that's not the case.

>  > If you want to bet
>
>Just show me the code.

That was the point of the bet.

>  > I'll put up $10 and a round of beer (or other
>>  beverage of your choice) at OSCON 2004 for all the python labs & zope
>>  folks that says parrot beats the current python interpreter when
>>  running all the python benchmark suite programs (that don't depend on
>>  extensions written in C, since we're shooting for pure engine
>>  performance) from bytecode. Game?
>
>If you're talking about simple stuff like pystone, people have
>already done *interpreters* that can run that kind of bench-
>mark 5-25 times faster than CPython.  All it takes is a fast
>GC, call-site caching, some low-overhead primitives, and a
>fast calling mechanism.

Then pick one you consider more indicative. I don't much care, 
honestly--as long as it doesn't depend on C extensions it's fine.

>But if you want to run real Python programs, you still have to
>solve all the hard problems.  Judging from the Parrot material
>I've seen, it's not obvious that you're even aware of what they
>are.

I have a list of hard problems. Luckily for me, python doesn't hit 
any of them, but that may as much be because of what I consider a 
"hard problem" than anything else.

>After all, if you know how to solve them, wouldn't it be
>easier to tell us what you've done (or plan to do), instead of
>pointing to non-Parrot implementations of non-Python languages
>done by others?

If parrot was finished, sure. It's not, hence the 2004 date on the 
challenge (while I could meet the deadline for this year's OSCON, 
enough other things would get shuffled aside that it wouldn't be a 
good allocation of resources) and the Scheme and Smalltalk examples, 
which *do* exist, and have for quite some time. C'mon Fred, you 
*know* that if I just told you how I planned to solve the problems 
I'd get ripped to shreds (and rightly so) for handwaving past the 
implementation issues, and nothing I have now will satisfy, as it's 
not finished so there's always that "well, it isn't done yet" 
rejoinder. (Which, again, is both fine and appropriate)

Still, the challenge stands if you or anyone else wants to take me up 
on it. Catch me before OSCON 2003 and we'll go from there.
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk