On Thu, Jul 25, 2002 at 10:06:55AM -0700, Jun Sun wrote:
> Johannes Stezenbach wrote:
> > 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
> 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
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'
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?