From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgJnw-0004DX-SB for qemu-devel@nongnu.org; Sat, 25 May 2013 15:07:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgJnv-00059A-KP for qemu-devel@nongnu.org; Sat, 25 May 2013 15:07:00 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35045 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgJnv-000592-Bz for qemu-devel@nongnu.org; Sat, 25 May 2013 15:06:59 -0400 Message-ID: <51A10BCA.6000800@suse.de> Date: Sat, 25 May 2013 21:06:50 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lior Vernia Cc: qemu-devel@nongnu.org, =?UTF-8?B?6Zmz6Z+L5Lu7?= , Richard Henderson Hi, Am 24.05.2013 21:24, schrieb Lior Vernia: > I am running x86 applications on an ARM device using QEMU, and found > it too slow for my needs. Before we start going into technical details, what are you trying to achieve on a high level and how did you try to do it? Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0? > This is to be expected, of course, this is > not a complaint. Especially since most people still run on x86 ... > However, I was wondering whether this could be helped > by "overriding" the generic binary translation mechanism and focusing > on lower level binary translation just from x86 to ARM. >=20 > It's clear to me that this isn't a small project, but it might be > important enough for me to invest myself in. However, before I jump > into it, I wanted to inquire whether this would be worthwhile at all. > Does anyone have any estimate as to how big of a gain that could > achieve? Or whether a more significant improvement could be achieved > by further tweaking that didn't occur to me? ... the tcg/arm/ code does not get a lot of love, so you might be able to squeeze some more performance out of it by implementing optional TCG ops or optimizing existing implementations. In theory most TCG ops should correspond to a machine instruction (where available); there's a TCG-level optimizer to create more efficient code, but it's a tradeoff between time for code optimization and execution time. Needless to say that you should enable -O3 optimization (or something) for the core C code and not to enable debug features in configure for your performance measurements. :) Whatever implementation you experiment with, get familiar with our Git-based workflow and try to stay close to qemu.git code or otherwise you'll create a fork with little chance of getting integrated into the code base - meaning both we don't get your speedups and you don't get our latest features and bugfixes. One such example was the attempt to use LLVM instead of TCG. Regards, Andreas > Proper disclosure: I'm fairly new to this whole cross-architecture deal= . >=20 > Yours, Lior. --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg