From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,103803355c3db607 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.190.104 with SMTP id gp8mr7529198pbc.4.1341135078956; Sun, 01 Jul 2012 02:31:18 -0700 (PDT) Path: l9ni5521pbj.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!feeder.erje.net!newsfeed.straub-nv.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sun, 01 Jul 2012 11:29:25 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GNAT (GCC) Profile Guided Compilation References: <38b9c365-a2b2-4b8b-8d2a-1ea39d08ce86@googlegroups.com> <982d531a-3972-4971-b802-c7e7778b8649@googlegroups.com> <520bdc39-6004-4142-a227-facf14ebb0e8@googlegroups.com> In-Reply-To: <520bdc39-6004-4142-a227-facf14ebb0e8@googlegroups.com> Message-ID: <4ff01875$0$6568$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 01 Jul 2012 11:29:26 CEST NNTP-Posting-Host: 26e80134.newsspool3.arcor-online.net X-Trace: DXC=f02@aGQHRm[mG86`U=_nC_McF=Q^Z^V3X4Fo<]lROoRQ8kF_5CCM><;_PCY\c7>ejVXG^b7WPQ[lO_c^[ZZnVH4=[ X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-07-01T11:29:26+02:00 List-Id: On 29.06.12 19:03, Keean Schupke wrote: > Note: this is not really answering my question about the lack of improvement due to profile-guided compilation - but perhaps that side of things is more a compiler issue. Does anyone have any ideas about that side of things? In the few cases I have tried -fprofile-generate and -profile-use, there were more or less moderate improvements. For example, a program that writes a mandelbrot set executing on 4 cores runs in (user/real) 1.3s/10.0s and in 1.2s/9.3s, resp. Other things of interest included (perhaps nothing new here) preventing inline for some subprograms where inlining it would have had adverse effects. Maybe it was steering the optimizers in the wrong direction, preventing some better uses of registers.