On 11/07/03 Leopold Toetsch wrote:
> Very interesting. While we don't compete with typed languages, its nice 

Oh, but mono _will_ also compete with dynamically typed languages! :-)

> to see, that parrot execution speed is in the region of mono - for such 
> small tight loops.

Well, that was mono executing the same code a dynamic language like php,
python or perl would generate for running on the CLR.
I only implemented it in C# because I don't have the time to write a
perl/php/python compiler:-) If the loop was coded properly in C# it
would have been much faster (as it would have been much faster on parrot
as well if it used only integer and float registers).

> Register allocation AFAIK. PMCs are not in registers yet (only I- and 
> N-Regs). I dunno on which architecture you ran the test, but FYI 

Sorry, forgot to mention I have a 1.1 Pentium III (we currently have the
jit running only on x86, itanium and ppc).

> JIT/i386 calls vtable functions directly for simple opcodes like add. If 
> we have finally PMCs in registers too, we could safe more cycles...

Yes, I noted that the unoptimized parrot is only slightly slower than
the optimized build: this means that most of the code is jitted, good.

> A little thing is missing in your code: if num+num gives an equivalent 
> int, it should get morphed back to a PerlIV.

Oh, is that a requirement of the Parrot spec or PHP? AFAIK perl doesn't
behave that way (though in some configuration it tries to do operations
with integer arithmetric, the type is kept as a NV). The quick code I
put together isn't designed for such frequent type flip-flops, so I
fixed it with a suboptimal solution, but it's still very fast:
400 ms (it was 340 before, for reference parrot takes 580 ms).
For those interested, the Add method in PerlNV became:

        public override PerlBase Add (double v) {
                value += v;
                int c = (int)value;
                if (value == c) {
                        if (ivcache == null) {
                                ivcache = new PerlIV (c);
                                ivcache.nvcache = this;
                        } else {
                                ivcache.value = c;
                        }
                        return ivcache;
                }
                return this;
        }
A better solution would have been to store the values directly in PerlSV
and use the value field in it just as a fast dispatch for the different
vtables in PerlIV, PerlNV etc.

Thanks!

lupus

-- 
-----------------------------------------------------------------
[EMAIL PROTECTED]                                     debian/rules
[EMAIL PROTECTED]                             Monkeys do it better

Reply via email to