[EMAIL PROTECTED] wrote:
> Leopold Toetsch wrote:
>
> > parrot -j ord 1.10 user 1.26 real # opt. build rev 8072
>
> and another 20% by inlining the fast path of the array get (set_i_p_ki)
>
> 0.91 user 1.09 real # opt build rev 8076
I've written some files to go into ex
Leopold Toetsch wrote:
parrot -j ord 1.10 user 1.26 real # opt. build rev 8072
and another 20% by inlining the fast path of the array get (set_i_p_ki)
0.91 user 1.09 real # opt build rev 8076
Now its your turn to process files blockwise ;-)
leo
Leo,
Wow! That's quite a bit of JIT code that you've just rustled up! I'll have to
wait until this evening before I can properly try it, but those results look
real good! I guess comparison with the XS version is the 'fairest' (similar
executable size and startup time), in which case we're abou
Nick Glencross wrote:
Having looked into it a little further, it actually looks like the 'ord'
operation is a significant part of the (JIT) run, perhaps as much as
50%, which seems disproportionately high... (you can just comment out
the ord to see this)
Yeah, string_ord() isn't really fast, but
Leopold Toetsch wrote:
I have now implemented a C opcode and the one used signature for
MD5 as a JIT opcode for x86. But the speedup is much smaller: around 5%.
Thanks!
The problem with md5 code and Parrot JIT seems to be related to the
register allocator. md5 code is one big basic block of inte
Leopold Toetsch wrote:
Nick Glencross <[EMAIL PROTECTED]> wrote:
Still some way off the OS md5sum, which is typically 0.15 seconds, about
12x quicker. That may sound quite a bit, but much of it can probably be
accounted for by inefficiencies in my conversion to parrot code (a
slightly awkward rol,
Nick Glencross <[EMAIL PROTECTED]> wrote:
> Still some way off the OS md5sum, which is typically 0.15 seconds, about
> 12x quicker. That may sound quite a bit, but much of it can probably be
> accounted for by inefficiencies in my conversion to parrot code (a
> slightly awkward rol, and perhaps th
Nick Glencross <[EMAIL PROTECTED]> wrote:
> this patch makes some small updates to the MD5 files.
Thanks, applied.
leo
jerry gay wrote:
On 5/9/05, Nick Glencross <[EMAIL PROTECTED]> wrote:
- load_bytecode "library/Digest/MD5.imc"
+ load_bytecode "Digest/MD5.imc"
the '.imc' extension has recently fallen out of favor and is being
replaced with '.pir'. otherwise, looks good and works on
win32--msvc-7.1--perl
On 5/9/05, Nick Glencross <[EMAIL PROTECTED]> wrote:
> - load_bytecode "library/Digest/MD5.imc"
> + load_bytecode "Digest/MD5.imc"
the '.imc' extension has recently fallen out of favor and is being
replaced with '.pir'. otherwise, looks good and works on
win32--msvc-7.1--perl-5.8.6.
~jerry
Nick Glencross wrote:
Guys,
this patch makes some small updates to the MD5 files.
...
It would also be interesting for benchmarking, but I haven't got
around to trying
As a rough comparison running the md5sum.imc located in the examples
directory (on Linux/AMD Athlon), I get:
Empty file (to mea
11 matches
Mail list logo
