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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham 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.223.40 with SMTP id qr8mr5784566pbc.0.1342309235961; Sat, 14 Jul 2012 16:40:35 -0700 (PDT) Path: l9ni11739pbj.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Keean Schupke Newsgroups: comp.lang.ada Subject: Re: GNAT (GCC) Profile Guided Compilation Date: Sat, 14 Jul 2012 16:40:35 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <38b9c365-a2b2-4b8b-8d2a-1ea39d08ce86@googlegroups.com> <982d531a-3972-4971-b802-c7e7778b8649@googlegroups.com> <520bdc39-6004-4142-a227-facf14ebb0e8@googlegroups.com> <4ff08cb2$0$6575$9b4e6d93@newsspool3.arcor-online.net> <4ff1d731$0$6582$9b4e6d93@newsspool3.arcor-online.net> <4ff41d38$0$6577$9b4e6d93@newsspool3.arcor-online.net> <26b778c4-5abc-4fbf-94b0-888c2ce71831@googlegroups.com> <4ff43956$0$6576$9b4e6d93@newsspool3.arcor-online.net> <2dba1140-4f28-4fb8-ace4-2c10f3a02313@googlegroups.com> NNTP-Posting-Host: 82.44.19.199 Mime-Version: 1.0 X-Trace: posting.google.com 1342309235 9672 127.0.0.1 (14 Jul 2012 23:40:35 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 14 Jul 2012 23:40:35 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.44.19.199; posting-account=T5Z2vAoAAAB8ExE3yV3f56dVATtEMNcM User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-07-14T16:40:35-07:00 List-Id: On Saturday, 14 July 2012 23:32:49 UTC+1, Keean Schupke wrote: > On Saturday, 14 July 2012 21:43:20 UTC+1, Niklas Holsti wrote: > > On 12-07-14 23:17 , Keean Schupke wrote: > > &gt; > > &gt; Okay, I think I have tracked down the performance problem, = but I am > > &gt; not sure how to fix it. It would appear that C++ code that = returns a > > &gt; boolean from a function, generates a decision tree using te= sts and > > &gt; branches, whereas Ada is setting the result into a Boolean = variable. > > &gt; This has the result that C++ is bailing out of the evaluati= on as soon > > &gt; as it can (IE if one side of an and is false, or one side o= f an or is > > &gt; true), but Ada is always evaluating all parts of the expres= sions. > > &gt; > > &gt; Is this a difference in language semantics, and what is the= best way > > &gt; to deal with it? Do I need to rewrite all &#39;and&= #39; and &#39;or&#39; statements > > &gt; in conditionals as nested if statements to get the evaluate= only as > > &gt; far as necessary semantics like C/C++? > >=20 > > Use the short-circuit forms of &quot;and&quot; and &quot= ;or&quot;: &quot;and then&quot; and &quot;or else&quot;= . > >=20 > > --=20 > > Niklas Holsti > > Tidorum Ltd > > niklas holsti tidorum fi > > . @ . >=20 > Yes, this appears to be the biggest cause of the profile guided compilati= on not working as well for Ada as C++. With the short-circuit forms I get t= he following speeds (thousands of simulations per second). >=20 > C++: 40k, profile-guided: 56k > Ada: 40k, profile-guided: 54k >=20 > So thats a huge improvement (up from 46k to 54k). >=20 > Cheers, > Keean. After a bit of checking line-by-line to make sure I am using 'and then', 'o= r else' and 'constant' everywhere I can in the code, Ada is outperforming C= ++ when using profile-guided compilation for the first time. both C++ and A= da are getting about 40k simulations per second with normal compilation, C+= + is achieving 56k simulations per second profile-guided, and Ada 57k per s= econd. Cheers, Keean. On Saturday, 14 July 2012 23:32:49 UTC+1, Keean Schupke wrote: > On Saturday, 14 July 2012 21:43:20 UTC+1, Niklas Holsti wrote: > > On 12-07-14 23:17 , Keean Schupke wrote: > > &gt; > > &gt; Okay, I think I have tracked down the performance problem, = but I am > > &gt; not sure how to fix it. It would appear that C++ code that = returns a > > &gt; boolean from a function, generates a decision tree using te= sts and > > &gt; branches, whereas Ada is setting the result into a Boolean = variable. > > &gt; This has the result that C++ is bailing out of the evaluati= on as soon > > &gt; as it can (IE if one side of an and is false, or one side o= f an or is > > &gt; true), but Ada is always evaluating all parts of the expres= sions. > > &gt; > > &gt; Is this a difference in language semantics, and what is the= best way > > &gt; to deal with it? Do I need to rewrite all &#39;and&= #39; and &#39;or&#39; statements > > &gt; in conditionals as nested if statements to get the evaluate= only as > > &gt; far as necessary semantics like C/C++? > >=20 > > Use the short-circuit forms of &quot;and&quot; and &quot= ;or&quot;: &quot;and then&quot; and &quot;or else&quot;= . > >=20 > > --=20 > > Niklas Holsti > > Tidorum Ltd > > niklas holsti tidorum fi > > . @ . >=20 > Yes, this appears to be the biggest cause of the profile guided compilati= on not working as well for Ada as C++. With the short-circuit forms I get t= he following speeds (thousands of simulations per second). >=20 > C++: 40k, profile-guided: 56k > Ada: 40k, profile-guided: 54k >=20 > So thats a huge improvement (up from 46k to 54k). >=20 > Cheers, > Keean.