[pypy-dev] fast

Maciej Fijalkowski fijall at gmail.com
Sun Jan 11 21:16:15 CET 2009

On Sun, Jan 11, 2009 at 9:09 PM, Paolo Giarrusso <p.giarrusso at gmail.com> wrote:
> On Sun, Jan 11, 2009 at 13:26, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> We had this discussion couple of times already, but I'll try to recap.
>> On Sun, Jan 11, 2009 at 12:57 PM, inhahe <inhahe at gmail.com> wrote:
>>> With trace trees, hidden classes, aggressive type speculation, etc.,
>>> javascript engines run code about as fast as unoptimized C.
>>> And I know that Python isn't any more intractable than Javascript
>>> because pyjamas automatically translates from one to the other.
>> Well, wrong:
>> 1. pyjamas is translating python syntax to js syntax (even not all of
>> them). Which mean mostly that semantics are python. That said, you
>> cannot run the same program under python and under js after pyjamas
>> and expect the same result. Simple example would be as follow:
>> d[index]
>> In python, if d is a dictionary, this will raise KeyError, if d is a
>> list this will raise IndexError, if d is a custom object, it'll try to
>> call it's __getitem__. In JS however (after pyjamas) this will simply
>> be translated to d[index], which will return undefined if index is not
>> there (and not raise any exception).
> You have a point on semantic differences. However, such a problem does
> not make any of the two implementations faster than the other, and the
> error handling can be as slow as needed to make the common case fast.

I was just pointing out that argument is completely void since pyjamas
is not transforming semantics.

>> 2. python is far more complex than javascript, someone tried to count
>> LOC of our python implementation vs our javascript implementation and
>> it was something in order of 6-10x more code for python.
> Well, I expect your Python implementation to be far more optimized
> than your Javascript one, isn't it? And the 80-20% (or 90-10%) rule
> still applies. If the language allows fancier things, one would
> probably focus on standard practices. Take __slots__. Once one
> implements V8 maps, __slots__ becomes useless, and it's implementation
> would simply reuse the one for normal objects.

That's true.

> Also, if extra complexity is needed for weird stuff, most of the times
> it shouldn't affect the fast path. The existence of sys._getframe() is
> one of the exceptions, and f_lasti a particularly bad one (it has
> 10-20% impact on execution runtime).
>> It's also far
>> more dynamic.
> Can you explain why, or point to the archives where it was discussed?
> I made a quick search but I couldn't find the right keywords to use.

Well for various reasons. Take for example descriptor semantics or
metaclasses. I'm not up to discuss exactly which language is more
dynamic, because this is a valid point for static compilation. The
point is that python is more complex and require more effort to make
it fast.


More information about the Pypy-dev mailing list