develooper Front page | perl.perl5.porters | Postings from March 2013

Re: [perl #117239] Re: [perl #117259] Re:Bleadperlv5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz

Thread Previous | Thread Next
From:
Marc Lehmann
Date:
March 26, 2013 12:15
Subject:
Re: [perl #117239] Re: [perl #117259] Re:Bleadperlv5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz
Message ID:
20130326121450.GA4392@schmorp.de
On Tue, Mar 26, 2013 at 02:21:20AM -0700, "H. Merijn Brand via RT" <perlbug-followup@perl.org> wrote:
> I tested this yesterday with this code:

Your test wouldn't even execute the code, so any difference you measure
would be noise or worse.

> which is still faster than the original code.

Since the code you benchmark should be effectively identical this just
means you don't know how to interpret your own results, or you are running
into a compiler quirk (where change at one placed strongly affects code in
another, unrelated place).

Just for fun, and to waste more time that I could have used to actually do
productive and useful stuff for Perl, I made a real benchmark, albeit with
the current version of JSON::XS.

http://ue.tst.eu/c511fb5d9e4ebc2cd389d7716c706242.txt

I measured the runtime of the full program, not just the encodes.

With STACK_HES defined to 64 (the default), I get:

real    0m0.808s

With STACK_HES defined to 0 (basically disabling using the stack and always
using malloc):

real    0m0.938s

That's a 16% increase in runtime.

That probably doesn't mean much to p5pers who don't mind slowing down perl
by a factor of up to two because its fun to run your own mmu emulation in
the process emulation code, but it means a lot to JSON::XS.

Things get worse when you don't use method calls to call encode, and then
worse when you actually measure the calls only and then worse again when
you have many hashes and not just one, as all of these further reduce the
overhead. Things might get slightly better if alloca were used, depending
on the architecture and the stack layout used, but it would likely result
in even bigger differences, as addressing can potentially be done with one
indirection less.

All in all, my mini benchmark strongly favours malloc.

I never benchmarked this before, of course, but assuming that the
equivalent of alloca can't beat malloc by a large margin is naive at best.

The very fact that your test is apparently slightly faster with a much
slower function call should have been an enourmous wake-up call to you -
at the very least, you could have added an abort() to atcually check if
its actually being executed. But hey, it fooled Yves too.

I just hope when designing patches for perl and talking about differences
being in the noise, a bit more taste and common sense is applied. Or maybe
a tad more experience in programming.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About