Aaron Sherman <[EMAIL PROTECTED]> wrote: > On Tue, 2004-04-20 at 18:06, Leopold Toetsch wrote:
>> Well, yes. Except for the special case, which is nice though: >> >> $ time parrot ih.imc #[1] >> real 0m0.370s >> >> $ time perl i.pl #[2] >> real 0m5.656s > That's unrealistic. No. A real test. I did post all the ingredients. You can run it yourself. Using an array of natural ints (which you can declare in Perl6) filling these with values and incremeting (or doing some operation on these. > ... In P6, you should be able to take: > @a >>+<< @b > and turn it into: I don't get that shuffling tmp's around. Anyway, it doesn't matter. Of course the Perl6 compiler can roll it's own hyper loop for all the hyper ops. > Are we seriously suggesting that after JIT, that's going to be as slow > as raw Perl, or even any slower than: > .local ? PerlArray tmp1 > hyper > tmp1 = __Perl_Ary_a >>+<< __Perl_Ary_b For example: With the C<hyper> prefix (and the internal implementation) Parrot will know that this operation will use C<max(@a.elem, @b.elem) + 1> new PMCs. So before even starting this operation, we can query the memory subsystems and if there are less free PMCs, we can trigger a DOD run and turn DOD *off* - it want be of any use, to run more DOD runs - these can't yield more recycled PMCs. So instead of running 100 useless DOD runs, we run one. > ?! If so, I'm curious to know why. It seems to me that you're just > moving the work from the Perl 6 compiler all the way down to the JIT, > but the resulting code is the same, no? No. Parrot can e.g. access List internals. Look at my patch in the original post. And there was *no* JIT involved with the C<hyper> op. leo
