develooper Front page | perl.perl5.porters | Postings from January 2001

performance tweaking benchmarking (was Re: Tweaked config for Solaris/sparc == 30% perfomance boost)

Thread Previous | Thread Next
Nicholas Clark
January 9, 2001 08:46
performance tweaking benchmarking (was Re: Tweaked config for Solaris/sparc == 30% perfomance boost)
Message ID:
On Tue, Jan 09, 2001 at 04:17:31PM +0000, Alan Burlison wrote:
> Interestingly enough, the difference between the 'make test' results is
> only about 15%.  I suspect this is because the test suite is a series of
> relatively short 'straight line' code that doesn't involve lots of loops
> or object creation.

> The moral of the story is the test suite is not a good benchmark.

What is? perlbench?

It's a serious question. "Playing" around with the numeric conversion to
make 64 bit integers work well meant that I was finding that some changes
made the testsuite faster, some made it slower. However, if the testsuite
isn't representative of "real" code, what is?

For example, over the weekend I re-wrote looks_like_number to do the
strto[a-z]*l() conversion as it went (and unrolled the loop a bit and
tried to write it in a simple way so that gcc's optimiser made decent code.
It did; I don't think I could beat it in hand written assembler, 6
instructions per character-that-might-be-a-digit)

I find that op/numconvert.t is about 3% faster on an AMD K6, but the whole
testsuite is pretty much no slower or faster. I'm assuming that it will
help maintainability (there's less conditional compilation code, less need
to probe for working strtouq() or strtoull() or strtoul() or whatever it's
called on someone's system) but I'd like to know what tweaks there and
elsewhere might benefit average real perl programs (seeing as some of the
other things I've tried make measurable speedups or slowdowns) so by
changing internal compromises to better reflect the majority of perl programs
out there the sum of several small speedups should be a medium speedup.

I'm also assuming that Jarkko may not really want it until HP-UX and Irix
are happy with the current stuff.  (I *think* the bugs are out, but the
first test that verifies that "-3.14" is not a negative integer isn't until
lib/st-06compat.t so it seems there's no test checking the sanity of basic
integer operations)

And I've no idea why HP-UX and Irix are not happy, other than a hunch that
it's compiler casting issues (IIRC casting out of range values to integers
is undefined, so compiler isn't wrong) and that it's hard for me to
experiment as I don't have login to one of these with a compiler. (and hard
for anyone else as they won't have as good idea of what it might be)

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About