From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21428 invoked by alias); 1 Aug 2014 11:59:34 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 21418 invoked by uid 89); 1 Aug 2014 11:59:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: DUB004-OMC4S35.hotmail.com Received: from dub004-omc4s35.hotmail.com (HELO DUB004-OMC4S35.hotmail.com) (157.55.2.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA256 encrypted) ESMTPS; Fri, 01 Aug 2014 11:59:31 +0000 Received: from DUB121-W22 ([157.55.2.73]) by DUB004-OMC4S35.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Fri, 1 Aug 2014 04:59:28 -0700 X-TMN: [hD91Wwr3myt0RhCowTDJhYyKuOHNfKim] Message-ID: From: Alain Meunier To: "gcc-help@gcc.gnu.org" Subject: RE: shared libraries + lto ? Date: Fri, 01 Aug 2014 11:59:00 -0000 In-Reply-To: <20140801104716.GA11564@ioooi.vinc17.net> References: ,<20140801104716.GA11564@ioooi.vinc17.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00004.txt.bz2 Thanks Vincent, =20 I think I will not use shared libraries in this case. I will stick static ones. =20 But on the whole net there are many different expressions of correctness wh= en related to lto. Could you clarify : =20 say I have a static library libfoo.a: void function cool(int * restrict a,int * restrict b){ =A0=A0=A0=A0=A0=A0 //do something useful } =20 I also have=A0 libbar.a: void function eatTheWorld(int * restrict a,int * restrict b){ =A0=A0=A0=A0=A0=A0 //do something useful } Both compiled with gcc=20 gcc /*optim. flags here*/ -fPIC foo.c -o libfoo.a -flto gcc /*optim. flags here*/ -fPIC bar.c -o libbar.a -flto =20 and a main program my_app.c : =20 #include here int main(){ =A0=A0=A0 int f1 =3D 5; =A0=A0=A0 int f2 =3D 3; =A0 =A0 cool(&f1,&f2); =A0 =A0 eatTheWorld(&f1,&f2) =20 return 0; } =20 I will compile it with gcc /*optim. flags here*/=A0 my_app.c -lfoo -lbar -flto =20 Is that it ? Nothing more ? =20 This article suggests otherwise : http://hubicka.blogspot.fr/2014/04/linkti= me-optimization-in-gcc-2-firefox.html =20 No plugin or all this mess ? I am on Debian testing 64 bits. =20 The lto best use is still a bit unclear to yield the best performance, at l= east to me. ---------------------------------------- > Date: Fri, 1 Aug 2014 12:47:16 +0200 > From: vincent+gcc@vinc17.org > To: gcc-help@gcc.gnu.org > Subject: Re: shared libraries + lto ? > > On 2014-08-01 11:09:38 +0200, Alain Meunier wrote: >> I would like to know if one can use lto with shared libraries and >> leverage all the goodness of both worlds ? >> >> My tests show that it works but not sure if lto brang something or >> not in the game. > > I did some timings with MPFR + GMP two years ago and I found that it > was useless to use LTO with the shared library (I even wonder whether > this can make sense at all). Here are the results: > > Precision 10: > shared static > arg macro arg macro > Default 3.480 3.470 2.670 2.690 > LTO paths 4.000 3.980 2.640 2.660 > With LTO 4.110 3.970 2.320 2.410 > > Precision 80: > shared static > arg macro arg macro > Default 5.520 5.470 4.950 5.000 > LTO paths 5.510 5.500 4.440 4.470 > With LTO 5.540 5.520 4.040 4.120 > > Precision 300: > shared static > arg macro arg macro > Default 6.770 6.560 5.950 5.960 > LTO paths 6.140 5.980 5.060 5.020 > With LTO 5.980 5.960 4.280 4.400 > > Conclusion (on these examples): > * There isn't much difference between a precision given in argument > and a fixed precision given via a macro (known at compile time of > the main program). > * Using a static library instead of a shared library can yield a > speedup of up to 44% (this happens with LTO enabled), i.e. that's > almost twice as fast! > * LTO should be used only with -static (for performance, but also > when considering practical use, it is pointless to use LTO with > shared libraries). > * The LTO speedup ("With LTO" compared to "LTO paths" in static) can > be up to 15% (28% if we compare to the default static library, but > we are not just measuring LTO in this case). > * The LTO speedup compared to traditional linking (shared library > from the vendor, here Debian/unstable) can be up to 37%. > > Note: The versions of MPFR in "Default" (Debian packages providing > MPFR 3.1.0-p10) and with LTO paths (MPFR 3.1.1-p2) are not exactly > the same, but the differences consist only of bug fixes, so that the > tested source code should be the same. > > -- > Vincent Lef=E8vre - Web: > 100% accessible validated (X)HTML - Blog: > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) =20=09=09=20=09=20=20=20=09=09=20=20