From owner-freebsd-arch@FreeBSD.ORG Thu Dec 27 19:09:15 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35562103 for ; Thu, 27 Dec 2012 19:09:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE6C8FC0A for ; Thu, 27 Dec 2012 19:09:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBRJ95dg047998; Thu, 27 Dec 2012 21:09:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBRJ95dg047998 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBRJ94vK047997; Thu, 27 Dec 2012 21:09:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Dec 2012 21:09:04 +0200 From: Konstantin Belousov To: Bruce Evans Subject: Re: UPDATE Re: making use of userland dtrace on FreeBSD Message-ID: <20121227190904.GL82219@kib.kiev.ua> References: <50D49DFF.3060803@ixsystems.com> <50DBC7E2.1070505@mu.org> <50DBD193.7080505@mu.org> <50DBE0DB.6090804@ixsystems.com> <20121227214354.V965@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kaF1vgn83Aa7CiXN" Content-Disposition: inline In-Reply-To: <20121227214354.V965@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 19:09:15 -0000 --kaF1vgn83Aa7CiXN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 27, 2012 at 11:39:44PM +1100, Bruce Evans wrote: > After working around these bugs by putting the functions in separate files > (and removing the now-unneeded volatiles): >=20 > main.c: > % void foo(void); > %=20 > % int > % main(void) > % { > % int i; > %=20 > % for (i =3D 0; i < 100000000; i++) > % foo(); > % } >=20 > foo.c: > % void bar(void); > %=20 > % void > % foo(void) > % { > % bar(); > % } >=20 > bar.c: > % void > % bar(void) > % { > % } >=20 > we can seem how much the frame pointer optimization is saving: this > now takes 0.43 seconds with clang and 0.87 seconds with gcc. It > is weird that the gcc time increased from 0.65 seconds to 0.87 > despite doing less. After adding back the volatiles, the times > are 0.43 seconds with clang and 0.85 seconds with gcc -- doing > more gave a small optimization, but didn't recover 0.65 seconds. > There is apparently some magic alignment or misalignment which > costs or saves about the same as omitting the frame pointer. > Finally, with gcc -O -fomit-frame-pointer, the program takes 0.60 > seconds, and with gcc -O2 -fomit-frame-pointer, it takes 0.49 > seconds, and with gcc -O2, it takes 0.49 seconds (this really doesn't > omit frame pointers, so omitting the frame pointer saves nothing), > With cc -O -fno-omit-frame-pointer, it takes 0.43 seconds, but this > case is just broken -- the -fno-omit-frame-pointer is silently ignored :-= (. I do not believe this measurement is indicative. i386 is register-starved architecture. Using the frame pointer means that you are left with only 6 registers instead of 7. For the PIC code, there are 5 vs. 6. It is real code that does something more than incrementing the same variable which could get the performance hit with -fno-omit-frame-pointer for i386. But on i386 use of the frame pointer is ABI mandated. For amd64, there is no so high pressure on the register file, but I do not know that much debugging tools which expect the frame pointer on amd64 or could detect and use it if present. It is only ddb for our kernel and dtrace for solaris and freebsd, gdb definitely does not. > >>>> need a dwarf2+ unwinder and somebody to instrument the call frame > >>>> state through the remaining assembler code. >=20 > I wouldn't want it for ddb. ddb doesn't have access to any debug info > except the symbol table. The unwind tables are not debugging. They, if requested, are put into the loadable segments. The dwarf unwind is required by the ABI on amd64, and is specified for all other architectures. --kaF1vgn83Aa7CiXN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ3JzQAAoJEJDCuSvBvK1ByjUP/0UMeSEc4y+znGd8MKkOCGSN jT0IQVP/AHelgzfCA9dbnAGlCTF+W5b1VBZHh98ampB37oXJZAYbKlm04vt9uVDF eInFtn8XUhOgUJGMb4cYOtOIjiYHzoOa818pyD2oHkZ++TX7swJsnXGVMVciyUfh VnSKf2gwi0kIjTWbRnPB3JqbEqJYD8JcwFvechId+hlr4Mzm5cX20cc2IFjgPVgE pwt8b41dgyX7UDKAWwvribySbiZkvbwIucZYehx21AS9XvEyl55n38KHK+SiVtCb MS8fdm8VD7WaHqXHwnfAywWmOp1ahsvnf7rzWuxqYxXftrIUsYM8GGCEtddJcGR5 ab7lALUzuzOKnveLMEhBfZqUg38xYUkiqKG86L3n2Zvyry5wA9xdfq4NyiCmXtBI 0AXdgyo+8aUAH20YqB2nRbd/g7Y76a/aqkCauzQ38H1jkqwUW9DI2SM8K2rElZYL W077i/+SF5C+aVRInEP4tQkKIdP2/lM+z2tzkV4cWEIMMCDJ+3owVxj22YhWIhlJ erX/+HUv727gMZdnLPodbXqeGm6MdQovfUJQo4HsmXQQFrAnywgvRWqOX2ZBs36O OtFSzcIlS5pWMATBXLG3kzsTccGqE+iJ6qst33zd442oTPrBEYawAPf8JXIMA4Z+ 9AA78vbTrXdKID3b0x7m =h0nY -----END PGP SIGNATURE----- --kaF1vgn83Aa7CiXN--