[Mono-devel-list] mono AES performance woes (was: poor PPC JIT output)

Paolo Molaro lupus at ximian.com
Mon Jul 18 05:59:17 EDT 2005


On 07/15/05 Allan Hsu wrote:
> Is there any reference on what sorts of things you can change using  
> mono_set_defaults? Following the mono source for references to that  
> function wasn't particularly enlightening. It would be useful if the  

grep mono_set_defaults *.c
mini.c:mono_set_defaults (int verbose_level, guint32 opts)
Should be pretty evident. Just always use the result of
mono_parse_default_optimizations (NULL) as the opts value.

> To be fair, the native implementation is able to take advantage of 64- 
> bit processors when available, while all mono builds in the above  
> benchmarks are 32-bit. The Windows XP machine is the standard 32-bit  
> install, even though the processor is 64-bit. This is a pretty  
> informal benchmark, but all I'm interested in showing here is how bad  
> the AES performance under mono is.

The current implementation causes lots of spilling and other
unnecessary work which the jit doesn't remove (the work massi is
doing should improve this). Some parts of it can be easily changed
to use unsafe code and that should improve performance a lot: I'll leave
that to Sebastien:-)

> >Some of the data looks definitely bogus: it reports a stall even on
> >the addi, here:
> >
> >    0x2e143c8 lwz      r4,32(r1)    3:1 Stall=2
> >    0x2e143cc lwz      r5,12(r4)    3:1 Stall=2
> >    0x2e143d0 cmplwi   r5,0x0000     3:1 Stall=2
> >    0x2e143d4 blel     $+696 <0x2e1468c [8B]>    2:1
> >0.4%    0x2e143d8 addi     r4,r4,16     2:1 Stall=1
[...]
> As for the stall statistics, you have misread them. Each line that  
> says "Stall=N" is saying that the instruction latency of the marked  
> instruction will cause a subsequent dependent instruction to stall,  
> not that the marked instruction itself will stall. N is the maximum  
> number of stall cycles for the nearest dependent instruction. The  

Since the tool reports that the addi stalls only sometimes (check the 
similar code sequences where no stall is reported), my take
is that your interpretation or the data reported is not correct.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better



More information about the Mono-devel-list mailing list