From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HdoNz-0003eV-CM for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:10:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HdoNw-0003eA-M1 for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:10:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HdoNw-0003e7-FK for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:10:20 -0400 Received: from damascus.uab.es ([158.109.168.135]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HdoJC-0000qf-48 for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:05:26 -0400 Received: from damascus.uab.es ([127.0.0.1]) by damascus.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0JGN00GWPB5100E0@damascus.uab.es> for qemu-devel@nongnu.org; Tue, 17 Apr 2007 16:05:25 +0200 (CEST) Received: from [158.109.70.47] by damascus.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0JGN0067QB516020@damascus.uab.es> for qemu-devel@nongnu.org; Tue, 17 Apr 2007 16:05:25 +0200 (CEST) Date: Tue, 17 Apr 2007 16:05:54 +0200 From: Marius Monton Subject: Re: [Qemu-devel] time inside qemu In-reply-to: <200704161612.40523.paul@codesourcery.com> Message-id: <4624D442.7000406@uab.cat> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pCVPVNOHTugcoC554BuVoA)" References: <459540A8.8020209@uab.cat> <200612291810.41992.paul@codesourcery.com> <46238B18.1080308@uab.cat> <200704161612.40523.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --Boundary_(ID_pCVPVNOHTugcoC554BuVoA) Content-type: multipart/alternative; boundary="Boundary_(ID_8kUG9y/DJY6v5rv3RWe8eg)" --Boundary_(ID_8kUG9y/DJY6v5rv3RWe8eg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE En/na Paul Brook ha escrit: > On Monday 16 April 2007 15:41, Marius Monton wrote: > =20 >>> Any benchmark/performance measurements you make inside qemu are >>> meaningless. qemu performance bears no relation whatsoever to the >>> performance characteristics of real hardware. >>> =20 >> That's true, and I don't care about it. I'd like to get a method t= o >> stop/start time inside qemu in order to simulate execution of larg= e >> pieces of hw out of qemu (look at qemu-systemc project). >> If qemu is freeze meanwhile a systemc simulation is in progress >> (simulating a HW device of system), time should be freeze also. >> In this way, execution time of a program inside qemu should appear >> shorter when using accelerator HW than only SW application. I know= these >> times are not reals, but it should be enough to estimate correctne= ss and >> execution time on real platforms. >> =20 > > You're deluding yourself. I simply don't believe you can get any me= aningful=20 > performance measurements out of qemu. You certainly can't use it to= evaluate=20 > the correctness of time sensitive algorithms. > > qemu execution times can easily be orders of magnitude different fr= om real=20 > hardware. i.e. if you have two operations that take the same amount= of time=20 > to execute on real hardware, one of those operations may take many = times=20 > longer than the other inside qemu. > =20 It's possible, but I think that roughly speaking, more code implies m= ore time: code (a) : for (int i =3D 0; i< 1000000; i++) c[i] =3D a[i] * b[i]; code (b) : for (int i =3D 0; i< 1000; i++) for(int j =3D 0; j < b[i]= ; j++) c[i] +=3D a[i]; code (c) : for (int i =3D 0; i< 1000; i++) c[i] =3D HW_MUL(a[i], b[i]= ); I'm sure that code (b) will execute much longer that code (a) inside qemu (sure that different that in real platform), and I'd like to compute executing time for code (c) in some way. So, how can I trap time information/calculation inside qemu? > =20 > If nothing else you're entirely at the mercy of the host OS process= scheduler=20 > and signal delivery. The emulated CPU may stall for an arbitrary ti= me at any=20 > point. > > =20 Sure, but this can be avoided using multiple simulations and calculat= ing arithmetic mean for execution time. > Paul > > =20 --=20 M=E0rius Mont=F3n i Maci=E1n marius.monton@uab.cat http://cephis.uab.es Hardware Engineer CEPHIS Centre de Prototips i Solucions Hardware-Software Dep. Microelectr=F2nica i Sistemes Electr=F2nics ETSE - Universitat Aut=F2noma de Barcelona (UAB) =09Phone: +34 935 81= 3 534 Fax: +34 935 813 033 QC-2090D. ETSE. Campus UAB. 080193 Bellaterra --Boundary_(ID_8kUG9y/DJY6v5rv3RWe8eg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE

En/na Paul Brook ha escrit: 
On Monday 16 April 2007 15:41, Marius Monton wrote:
  
Any benchmark/performance measurements you make =
inside qemu are
meaningless. qemu performance bears no relation whatsoever to the
performance characteristics of real hardware.
      
That's true, and I don't care about it. I'd like t=
o get a method to
stop/start time inside qemu in order to simulate execution of large
pieces of hw out of qemu (look at qemu-systemc project).
If qemu is freeze  meanwhile a systemc simulation is in progress
(simulating a HW device of system), time should be freeze also.
In this way, execution time of a program inside qemu should appear
shorter when using accelerator HW than only SW application. I know th=
ese
times are not reals, but it should be enough to estimate correctness =
and
execution time on real platforms.
    

You're deluding yourself. I simply don't believe you can get any mean=
ingful=20
performance measurements out of qemu. You certainly can't use it to e=
valuate=20
the correctness of time sensitive algorithms.

qemu execution times can easily be orders of magnitude different from=
 real=20
hardware. i.e. if you have two operations that take the same amount o=
f time=20
to execute on real hardware, one of those operations may take many ti=
mes=20
longer than the other inside qemu.
It's possible, but I think that roughly speaking, more code implies more time:

code (a) : for (int i =3D 0; i< 1000000; i++) c[i] =3D a[i] * b[i]= ;

code (b) : for (int i =3D 0; i< 1000; i++) for(int  j =3D 0; = j < b[i]; j++) c[i] +=3D a[i];

code (c) : for (int i =3D 0; i< 1000; i++) c[i] =3D HW_MUL(a[i], b= [i]);

I'm sure that code (b) will execute much longer that code (a) inside qemu (sure that different that in real platform), and I'd like to compute executing time for code (c) in some way.
So, how can I trap time information/calculation inside qemu?
=20
If nothing else you're entirely at the mercy of the host OS process s=
cheduler=20
and signal delivery. The emulated CPU may stall for an arbitrary time=
 at any=20
point.
Sure, but this can be avoided using multiple simulations and calculating arithmetic mean for execution time.
Paul

--
Màrius Montón i Macián   <= font color=3D"#00ffff">marius.monton@uab.cat   http://cephis.uab.es
Hardware Engine= er
 Centre de Proto= tips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB) = 		Phone: +34 = 935 813 534
 Fax: +3= 4 935 813 033
 QC-2090= D. ETSE. Campus UAB.
 080193 Bellaterra
--Boundary_(ID_8kUG9y/DJY6v5rv3RWe8eg)-- --Boundary_(ID_pCVPVNOHTugcoC554BuVoA) Content-type: text/x-vcard; charset=utf-8; name=marius.monton.vcf Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: attachment; filename=marius.monton.vcf begin:vcard fn;quoted-printable:M=3DC3=3DA0rius Mont=3DC3=3DB3n n;quoted-printable;quoted-printable:Mont=3DC3=3DB3n;M=3DC3=3DA0rius org:CEPHIS-UAB adr:Campus de la Autonoma;;QC-2090D. ETSE;Bellaterra;Barcelona;08193;= Spain email;internet:marius.monton@uab.cat title:System Engineer tel;work:+34935813534 url:http://cephis.uab.cat version:2.1 end:vcard --Boundary_(ID_pCVPVNOHTugcoC554BuVoA)--