From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29038 invoked by alias); 1 Aug 2002 15:32:11 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 29029 invoked from network); 1 Aug 2002 15:32:04 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 1 Aug 2002 15:32:04 -0000 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id E7ED3B8049; Thu, 1 Aug 2002 11:32:03 -0400 (EDT) Received: (from fche@localhost) by toenail.toronto.redhat.com (8.11.6/8.11.6) id g71FW3B17787; Thu, 1 Aug 2002 11:32:03 -0400 Date: Thu, 01 Aug 2002 08:32:00 -0000 From: "Frank Ch. Eigler" To: Scott Dattalo Cc: sid@sources.redhat.com Subject: Re: Profiling: --insn-count=1 Message-ID: <20020801113202.C16668@redhat.com> References: <20020801071823.A7358@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from scott@dattalo.com on Thu, Aug 01, 2002 at 05:03:55AM -0700 X-SW-Source: 2002-q3/txt/msg00009.txt.bz2 --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2168 Hi - On Thu, Aug 01, 2002 at 05:03:55AM -0700, Scott Dattalo wrote: > [...] > Yeah, I suspected as much... If I had time to look into it, I'd try to add > that feature. The way I'd approach it is I'd partition the time it takes > an instruction to execute into two parts: the fixed amount of time the CPU > requires and the (possibly) variable amount that the memory accesses > require.=20=20 > The fixed portion may be ascertained when the target program is > first loaded.=20 This computation is hard, totally target-dependent. See for example the amount of work needed in gcc to model a CPU pipeline in detail (especially the more-precise DFA models). > The variable portion may too, depending on the address > accessed. [...] SID already does this part. You can configure memory modules, mappers, caches, and a few other bits as having latency counts associated with operations. The CPU accumulates these as penalties, combines them with a raw instruction count, and tells the target-time scheduler the sum. So simulated target time already includes the effect of these parameters. > [...] > The development scenario has thus been: >=20 > 1) make optimizations to the code and test on a Linux box > 2) debug and go back to step 1 about 100 hundred times or so. > 3) Once convinced that an optimization has been correctly made > re-target the makefile for an ARM processor > 4) simulate the code (using sid as the simulator engine, of course) > 5) analyze the simulation results (You may also opt to have both linux & arm builds go in parallel, and cross-check results for consistency.) > So far, I've been satisfied knowing the total number of executed > instructions. Objective results are easily quantified. However, I'm now > rapidly approaching the point where the optimizations have been completed= .=20 > While I know the approximate number of instructions, I still do not know= =20 > the total number of CPU cycles (and hence the total time). > [...] To get the most precise answer, you'd best use hardware running a profiling-capable OS. If accounting for approximate memory latencies is good enough, then SID can be of help. - FChE --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 232 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9SVRyVZbdDOm/ZT0RAlVUAJ0eTASWB137ODdQnhaIy+cspdXEpQCfXvtI su2TlCFmMGaEFGYTlpQQJVQ= =2Uz7 -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX--