[pypy-dev] fast

[Paolo Giarrusso]

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.

> 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.

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.

> 3. Psyco runs programs (let's say integer computations) as far as
> unoptimized C. Our prototype JIT does as well and we're working hard
> on improving things (in fact we work a lot on JIT these days).

-- 
Paolo Giarrusso