qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to spe


From: Aurelien Jarno
Subject: Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation?
Date: Fri, 21 Aug 2015 18:13:22 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On 2015-08-21 08:47, Richard Henderson wrote:
> On 08/20/2015 11:05 PM, Dennis Luehring wrote:
> >> > g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c 
> >> > -MMD -MP
> >> >
> >> > tcg-indirect: ~2:46.5
> >> > qemu.org-git: ~2:51.2 (worst result)
> >> > without-optimization: ~2:14.1 (best result)
> >>
> >> No compiler optimization?  I wouldn't expect there to be much for tcg to
> >> optimize there -- dropping values to memory all the time doesn't leave 
> >> much.
> > 
> > 
> > without-optimization means qemu.org-git release build + undefine
> > USE_TCG_OPTIMIZATIONS in tcg/tcg.c
> > or what compiler do you mean?
> 
> The one for compiling the benchmark: g++ -O2.
> 
> >> These results are weird.  Unoptimized less than half the speed of mainline?
> >> Improving optimization (with no extra work, mind) brings the results back 
> >> down?
> > 
> > 
> > yep they are - it seems that the assumption of the involved developers
> > where speed can be improved / or slowbess comes from is not correct
> > how are SPARC64 benchmarks done usually?
> 
> *shrug* No different than any other...

It would be interesting to know if the time taking to generate code is
actually used for code translation or code re-translation. The way the
MMU is modelled might triggered plenty of costly retranslation. This
happens for example on SH4, and to a lesser extent on MIPS.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]