That's why I was surprised. Even if it doesn't improve performance (something it was never supposed to do in the first place), the question is whether it hurts performance significantly, e.g. whether the tradeoff between better code and faster code is worth it. Currently, I see no evidence that it significantly hurts performance, which was, IIRC, the only objection to the patch. Also, it's quite easy to change the benchmark time: just add another zero to the command-line parameter, and it'll take about ten times as long.
P.S. Thanks for the link! That'll come in handy. Alek Storm On 3/31/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Mar 30, 2007, at 9:19 PM, chromatic wrote: > On Friday 30 March 2007 13:59, Alek Storm wrote: > >> I used a simple benchmark to compare the relative speeds of Parrot >> with and without the patch, and I was surprised to find that the test >> script runs (very roughly) 10% faster *with* the patch. Can someone >> confirm this? Running revision 17860; benchmark script attached; run >> as: >> $ parrot bench.pir 100000 >> >> Since leo was concerned about memory usage, by running valgrind: >> $ valgrind --tool=massif parrot bench.pir 100000 >> I found that, over several runs, the spacetime (time * bytes) usage is >> slightly better with the patch than without. Can someone confirm this >> also? > > The results look statistically noisy to me, as of r17872, on x86 Linux. > > -- c I'm on ppc, and after making a change to get it to compile(not a portable patch, but that's another issue), and I'm not noticing any statistical difference. I didn't run your minibenchmark, but there are other benchmarks I used, such as those in examples/shootout. In the cases where I think I get a result, a few runs later of both eliminate any difference(which could be due to caching). Also, judging by chromatic's results, any benchmark that finishes in under a fifth of a second isn't a good benchmark. So needless to say, it doesn't seem as though your patch does any good for performance(more often it seemed worse but I didn't get enough results to really check). For subtle things like this, try reading http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ testing.html and see if it helps you any on how to benchmark changes. Now, with regard to the other issues, final decisions about what is best for how to handle reentrancy depend upon the makeup on whatever requires reentrancy. Your patch may or may not be the ideal solution to the problem.
