Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:

> Point of order: discussions would be a lot easier if they didnt *start
> out* with perjorative terms like "ugly hacks".  One of my goals is to
> eliminate the need for if (!Interp_flags_TEST(INTERP,
> PARROT_PYTHON_MODE)) sprinkled throughout the various "standard" (i.e.
> Perl) PMCs.

Sorry about that. These hacks of course include pieces like

    if (!Interp_flags_TEST(INTERP, PARROT_PYTHON_MODE))

and much more, which I have introduced. It was by no means intendend
against you.

> Yes, this all needs to be radically refactored - and all perlisms and
> pythonisms removed from the "standard" classes.

Yep.

> ....  Furthermore, it is
> clear that operators like "sub_p_p_p" and "set_p_p_kic" will always
> perform better than callmethodcc_sc "__sub__" and callmethodcc_sc
> "__getitem__" respectively.

Well, and that's not true. I've already shown the opposite:
Here are agains these numbers (-O3 build, AMD 800, 5 Meg operations):

MMD add PerlInt PerlInt 0.693220
MMD add PerlInt INTVAL  0.609069
MMD sub PerlInt PerlInt 0.475912
MMD sub PerlInt INTVAL  0.490149
PIR add PerlInt PerlInt 8.312403
PIR sub PerlInt PerlInt 4.562026

Please note the big speedup in the overloaded sub method.

The "add" opcodes use the existing code, the "sub" has internal opcodes
similar to:

  mmd_op_v_ppp .MMD_SUBTRACT, Pdest, Pleft, Pright

and

  mmd_op_v_ppp_PASM .MMD_SUBTRACT, Pdest, Pleft, Pright

But the sourcecode contains just the normal "sub" opcode. The method
call syntax should just visualize, what's happening internally.

"__getitem__" aka set_p_k_ic shows a moderate slowdown of 10%.

> Therefore, Pirate emits the opcodes whenever direct use is made of
> things like infix operators and square brackets.  And implemented
> methods like __sub__ which, while rarely used, will operate correctly by
> invoking to the opcodes.

Emitting opcodes is fine. Nothing will change on the surface. I'm
speaking about what the assembler does, if it encounters Px = Py[Pz]

> I *don't* see a need to heavily optimize for rarely used mechanisms.

I'm not speaking of any optimization.

Rarely or not doesn't really matter, if we currently just can't do an
equivalent of:

$ python

>>> from cmath import sin
>>> sin(1+2j)
(3.1657785132161682+1.9596010414216058j)

as long as "sin" is just a plain opcode internally. The compiler will
just emit a "sin" opcode. But *internally* its something like:

  P_cmath_namespace."sin"(...)

Or have a look at pie-thon b3.py:

T = int

class TT(T):
...
class Int(TT):
...
    TT.__cmp__ = T.__cmp__

By manipulating the compare method slot the derived class sorts
differently. If we don't do a method call internally, I can hardly
imagine, how to implement Python.

Just forget the speed argument. We optimize later.

> I encourage you to check out Pirate.  The IMCC output of pirate.py is
> now remarkably close to the output of pie-thon.pl.

I'll do.

> - Sam Ruby

leo

Reply via email to