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.
