The HLL Performance Gap

[Austin Hastings]

0. Is there a standard set of performance/timing tests? If not, can we 
make one?

In particular,

0a. How long does it take to initialize parrot and execute a single 
"HALT" instruction?

0b. How long does it take to perform opcode O, 10**X-sub-O times, for 
some appropriate value of X-sub-O, for each O?

0c. How long does it take to run a standard program, with functions and 
data and objects and file i/o, Y times?

0d. How long does it take to run (some troublesome subsystem 'S') 
Z-sub-S times?

=Austin


Patrick R. Michaud wrote:
> On Tue, Jul 21, 2009 at 04:31:20PM -0700, Geoffrey Broadwell wrote:
>   
>> THE ANALYSIS:
>>
>> A few weeks ago, I was able to spend some time trying to track down why
>> this huge performance gap existed, at least for my code running in
>> Rakudo.  I suspect that other HLLs face similar problems, and I'd love
>> to see what the rest of you have found.
>>
>> In any case, I found a number of issues, summarized in this list:
>>
>> 1. Every Perl 6 scope becomes a PIR sub.
>> 2. Rakudo scopes are extra-heavy.
>> 3. PCT has no optimization passes.
>>     
>
> All of these are valid issues, but personally I find that they are
> of *far* less importance than
>
> 4.  Parrot subroutine calls are far too slow
>     4a.  There is too much overhead in parameter passing
>
> So while I agree that we can get started on things like PCT optimizations,
> of far greater importance to HLL performance will be resolving
> Parrot's calling conventions and in speeding up the basic mechanisms
> for invoking and returning from Parrot subroutines.
>
> Phrased another way -- based on the measurements I've done, the
> speed overhead that currently exists in Rakudo arising from
> variable setup and takedown is far outweighed by the basic
> costs of performing subroutine calls.  While we may be able to
> eliminate some subroutine scopes (and I already have designs
> for doing this), the number of cases where this will in fact
> be possible is quite small.  Based on my experience in developing
> on Parrot, I suspect the fixes and optimizations you're describing 
> for Rakudo are in fact more of the "iterating on fixes that each 
> gain a few percent" variety than the "order of magnitude improvements".
>
> Again, I'm not saying that we shouldn't start looking at PCT
> improvements.  But I am saying that it's far more important
> that we stabilize Parrot's calling conventions early in the
> process -- not only for the performance improvements to be
> gained from doing so, but also because our ability to
> measure and adequately optimize PCT directly depends on the
> underlying stratum being stable and efficient.
>
> Pm
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>