Preening the parrot for show
Nicholas Clark
(or http://xrl.us/uy5m )
There's a comment from Matt Diephouse
Did you build an optimized version of Parrot to use with Cardinal?
By default, Parrot builds with all optimizations off and with all
debug flags on. This makes it slower but makes development a lot
easier.
The answer was "no"
I was wondering - are people doing benchmarks more likely to be using
release versions of parrot rather than svn head? If so, would it be a
good idea for positive publicity's sake to have the release versions
default to optimise?
Alternatively, given that gcc is capable of building with both debugging
and optimising, and a good number of people benchmarking will be on Linux,
would it be viable to make the default with gcc to be "-g -O2"?
Either way could try to skew third party benchmarks (and the unpublished
private benchmarks we don't even know about) in Parrot's favour.
Nicholas Clark
Tewk
I'm surprised that any benchmarks ran at all.
The current cardinal implementation is extremely minimal. Basically
simple arithmetic.
Kevin
Joshua Isom
On Feb 19, 2007, at 5:57 PM, Nicholas Clark wrote:
> There's a benchmark of Ruby implementations at
>
> http://www.antoniocangiano.com/articles/2007/02/19/ruby-
> implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-
> net-vs-rubinius-vs-cardinal
>
> (or http://xrl.us/uy5m )
>
> There's a comment from Matt Diephouse
>
> Did you build an optimized version of Parrot to use with Cardinal?
> By default, Parrot builds with all optimizations off and with all
> debug flags on. This makes it slower but makes development a lot
> easier.
>
>
> The answer was "no"
>
> I was wondering - are people doing benchmarks more likely to be using
> release versions of parrot rather than svn head? If so, would it be a
> good idea for positive publicity's sake to have the release versions
> default to optimise?
And at the same time, why have the default runcore be the slow core.
It's probably better for testing, but for the vast majority of cases,
-Cj is faster(although in some instance -j's faster, or -C is faster,
or even -S, just depends on the specific benchmark). If we have
release versions default to optimize, shouldn't we also try and default
to a faster runcore? An optimized parrot with a faster runcore greatly
increases speed.
> Alternatively, given that gcc is capable of building with both
> debugging
> and optimising, and a good number of people benchmarking will be on
> Linux,
> would it be viable to make the default with gcc to be "-g -O2"?
Also, looking through the gcc manpage, one thing caught my eye about
optimizing, with regards to CG and CGP. "Note: When compiling a
program using computed gotos, a GCC extension, you may get better
runtime performance if you disable the global common subexpression
elimination pass by adding -fno-gcse to the command line." It would be
interesting to benchmark this with parrot, as the cg and cgp runcores
work by computed gotos. But, gcse fails on the cgp core because it's
too complicated anyway so it may not matter. Anything for that
hundredth of a second, right?
Nicholas Clark
> Also, looking through the gcc manpage, one thing caught my eye about
> optimizing, with regards to CG and CGP. "Note: When compiling a
> program using computed gotos, a GCC extension, you may get better
> runtime performance if you disable the global common subexpression
> elimination pass by adding -fno-gcse to the command line." It would be
> interesting to benchmark this with parrot, as the cg and cgp runcores
> work by computed gotos. But, gcse fails on the cgp core because it's
> too complicated anyway so it may not matter. Anything for that
> hundredth of a second, right?
The counter to that is that if one can arrange for the compiler to do as
many (legitimate) yak shaving optimisations as possible, it frees the
programmer's time up to increase functionality (or find better algorithms).
Nicholas Clark