From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLygr-000358-7C for qemu-devel@nongnu.org; Sun, 02 Aug 2015 15:12:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLygl-0001H8-OI for qemu-devel@nongnu.org; Sun, 02 Aug 2015 15:12:57 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:34493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLygl-0001H4-JF for qemu-devel@nongnu.org; Sun, 02 Aug 2015 15:12:51 -0400 Received: by wibud3 with SMTP id ud3so111533956wib.1 for ; Sun, 02 Aug 2015 12:12:50 -0700 (PDT) References: <55B734A7.8040108@gmx.net> <55B8B122.7020406@gmx.net> <55B8DB46.6070307@gmx.net> <55B99E47.8070007@gmx.net> <55B9CE58.7030609@redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Sun, 02 Aug 2015 20:12:47 +0100 Message-ID: <87zj29zeq8.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: Paolo Bonzini , qemu-devel , Dennis Luehring , Karel Gardas Artyom Tarasenko writes: > On Thu, Jul 30, 2015 at 9:12 AM, Paolo Bonzini wrote: >> >> >> On 30/07/2015 05:47, Dennis Luehring wrote: >>> so your aarch64 is just less todo for qemu - not EVERY >= 16bit memory >>> access needs swapping or needs check for unaligned access to emulate >>> bus-erros >> >> Not to mention register windows, which IIRC are the big source of pain >> for SPARC. > > That's true. But then again there is an emulator called tme [1] which > doesn't do binary translation, > and still much faster then QEMU at least on a x86_64 host when > emulating a sun4u machine. > > 1. http://people.csail.mit.edu/fredette/tme/index.html That does seem weird. FWIW with QuickTransit's SPARC emulation we claimed "faster than native", e.g. we could get benchmarks that run faster under translation on the latest Intel hardware than the fastest production SPARC chips at the time. We did have the advantage of full FPU translation which is an area QEMU lags a little but that doesn't seem to be the problem here. I notice udivx is a helper function but I guess that's to make it's overflow and exception handling easier. > > Artyom -- Alex Bennée