The way to a faster python [was Python IS slow !]

[Markus Stenberg]

Christian Tismer <tismer at appliedbiometrics.com> writes:
> > I haven't looked at it in detail, so forgive me if I'm mistaken, but it
> > looks like it tries to do a straightforward translation of Python code
> > to C directly, without doing much parsing. Perhaps that cannot be
> > adapted easily to static types...

Depends; it has been talked about on mailing list for a bit. In general
though, it'd call for a rewrite of sorts (I'm just an observer who proposed
something _just_ like this about week ago and then ran out of time :->).
I'm going to take a look at it sometime this week.

> the code is simply so huge that I don't use it.
> 10 times faster, yes. But not for 30 percent.

That's primarily because py2c's main goal these days has been primarily to
get it to work; as it is, it basically unwraps Python code, turns it
directly into C, and that's it. But it does a lot of (possibly
unneccessary) things to ensure that it works in every case.

> [blode coat]
> > Naively I'd think code bloat could be fairly limited? Most of a Python
> > subset sounds like it could be expressed in C fairly easily. But I'm
> > sure I'm deluded here. :)
> Interpreting everything is as wrong as compiling everything.

True.

> Just try to pour the whole Pyhton linbary through P2C.
> How large would the binary be. 5MB, 10MB?

Around that size, probably, yes.

> Yes, and you know how careful it has to be for that :-)
> If we write something for a couple of hackers who
> take every risk, just for the cycles, well.
> But as a true language subset, with the same
> promise of error handling and not core dumping,
> you need to consider quite much.

Something Eiffel-ish might work, though, i.e. selecting at compile-time
whether to toss in all expensive checks and very special cases or not.

-- 
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler

We don't see a similarity. We really don't.