Re: LL/SC benchmarking [was: Mipsel libc with LL/SC online anywhere?]

[Johannes Stezenbach <js@convergence.de>]

On Thu, Jul 25, 2002 at 10:06:55AM -0700, Jun Sun wrote:
> Johannes Stezenbach wrote:
> >sysmips:
> >        real    1m19.358s
> >        user    0m28.150s
> >        sys     0m47.250s
> >
> >LL/SC emulation:
> >        real    0m41.246s
> >        user    0m25.390s
> >        sys     0m12.240s
> >
> >branch-likely hack (hm, still without kernel patch...):
> >        real    0m25.126s
> >        user    0m17.240s
> >        sys     0m2.310s
> 
> Johannes,
> 
> This is great stuff!  Can you explain what are "real", "user", and "sys"? 
> Also, what is your initial conclusion?

This are results from simple 'time ./testapp' testing, so its real time
and user/system time reported by wait(4).

Also, I have an interactive gtk+directfb applicaton running. The
difference in response time is quite noticable.

On reason for the big differences is that the Glib-2.0/GObject library
does a lot of locking in its internal type system for every object
created. Other software might not suffer as badly from a slow mutex
implementation.

My conclusion is that it is good for glibc to always use ll/sc,
emulated or not, and for my specific needs I will use the branch-likely
hack. So next I will study kernel source to decide what MAGIC_COOKIE
is best for the branch-likely hack, and where to add 'move k1,$0'
before eret.

OTOH I doubt it's worth it to add the branch-likely hack to
stock glibc. How many people are using Linux/MIPS on embedded
CPU's without LL/SC?


Johannes