[Mono-dev] [PATCH] Enable TLS for PPC32/64
munroesj at linux.vnet.ibm.com
Wed Feb 25 16:15:50 EST 2009
On Mon, 2009-02-02 at 15:53 +0100, Paolo Molaro wrote:
> On 01/28/09 Steven Munroe wrote:
> > if there WAS a problem will some chip in the past we address that
> > separately. But this changes are important to the server class machines
> > and I have carefully crafted this patch to only optimize for the case
> > where we know (from the auxv) what the hardware actually is.
> > Don't penalize the latest hardware for the sins of the a chip that no
> > one makes any more...
> You're asking us to accept a possibly risky change without providing any
> numbers on the benefits (which is what I requested in my mail).
> Right now the only numbers I have are this: when profiling mono on ppc I
> have never seen the icache flush function appear anywhere near the first
> few pages of hot code. As you say the change is "important" you won't
> have any difficulty in providing hard numbers and system information
> where mono gets a speedup with the change (running something like mono
> --compile-all /usr/local/lib/mono/2.0/gmcs.exe may be your best bet
> for exercising the icache flushing, but any relevant benchmark using
> mono you can come up with is fine).
> If you're looking at improving the speed of mono on ppc I can suggest
> many other things which will provide significant speedups (like for
> example remove FORCE_INDIR_CALL in mini-ppc.c).
I was at first delayed by trying to find a suitable benchmark but
eventually decided to use
time make check
as a first approximation
The average results of 5 runs on a 4.0GHz POWER6 is:
without opt patch:
and with opt patch:
So the opt patch is 2.65% (user, 1.56% real) faster then without. This
reflects the Instruction Cache Snooping capability of POWER6 (and
POWER5) and the simplification of the mono_arch_flush_icache() using
PPC_FEATURE_ICACHE_SNOOP as the runtime check.
I expect the results will be more pronounced with larger more complex
More information about the Mono-devel-list