On Wed, 2008-04-16 at 00:10 +0200, Leopold Toetsch wrote:
> Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> > Greetings all,
> >
> > I just posted a little Parrot benchmark in my use.perl's journal
>
> Just a reminder:
>
> Please don't use unoptimzed builds for benchmarking. There are a lot of code
> asserts and other slowdowns due to compiler goodwill in devel code.
>
> $ make realclean; perl Configure.pl --optimize && make
>
> should do it,
It might be worth building two parrots by default -- one debug for
normal work, and one optimized for benchmarking; perhaps call the second
one 'parrot-opt' or 'parrot-fast' or something similarly descriptive?
Heck, we could even reverse the huffmanization, and call the benchmark
parrot 'parrot', and call the one we do core development with
'parrot-debug'. Or equalize them, calling them 'parrot-debug' and
'parrot-opt', and symlink 'parrot' to 'parrot-opt'.
I'd even say to not only compile the benchmarking parrot with C compiler
optimizations on, but also set it to turn on the parrot optimization
flags (-O2 -Ot -Oc -Op -Oj etc.) by default -- whichever ones we would
generally recommend to a benchmarker (per platform).
Of course, then it would be nice to have 'make test-opt' to make sure
that the recommended C and parrot optimization flags actually result in
a working parrot.
I recommend all this mostly because of the number of benchmarkers who
persist in always using the default build, with the default (C and
parrot) optimization flags. I've heard a lot of reasons for this
behavior, but to me the two most persuasive are:
1. Average users will likely use the default config and no flags.
2. It's hard to determine the "recommended" benchmark config/flags.
Building a "fast parrot" in addition to the existing debug parrot
addresses both of these concerns. "Average users" will likely use
anything labeled "fast", especially if it's clear that the other option
is "debug". And the recommended benchmarking config and flags will be
baked into parrot-fast, so there's no question about the appropriate way
to build and use parrot when benchmarking.
The one remaining problem is if the build gets slowed down too much for
normal development. Several things may mitigate this:
1. As I recall a decent amount of the build time is spent in
the Perl scripts that preprocess and generate source files;
this time would probably not need to be duplicated, only
the actual C compile and link phases.
2. PASM and PIR code executed during the build (building
compilers based on PCT, for instance), or during testing,
can be run with the fast parrot by default, and only with
the slow parrot when needed.
3. It might be useful to add a config option to turn *off*
building the fast parrot, and just tell core Parrot
developers to use that if the build times are too long.
This config should also change the 'parrot' symlink to point
to 'parrot-debug' of course ....
Anyway, just a thought.
-'f
