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