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 ClarkThread Previous | Thread Next