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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7767a311e01e1cd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 21 Oct 2006 22:03:03 -0500 Date: Sat, 21 Oct 2006 23:03:14 -0400 From: Jeffrey Creem User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GNAT compiler switches and optimization References: <1161341264.471057.252750@h48g2000cwc.googlegroups.com> <9Qb_g.111857$aJ.65708@attbi_s21> <434o04-7g7.ln1@newserver.thecreems.com> <4539ce34$1_2@news.bluewin.ch> <453A532F.2070709@obry.net> <9kfq04-sgm.ln1@newserver.thecreems.com> In-Reply-To: <9kfq04-sgm.ln1@newserver.thecreems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 24.147.74.171 X-Trace: sv3-jGnodWUB8c+/i0aDqDKqQkQrMXsPZHfeo1mjwSN0pcl8yBUPf/TOrp3ofGVipFyBu/X71dXXuQa2xqJ!JPCOwAixGZD6vJEsxT1mGkKqxOGH0SBzEVQxGyHF7jyWXlSZMwlTXHPXmGAgkuAwqZcvM+q+VDEU!Duo= X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:7124 Date: 2006-10-21T23:03:14-04:00 List-Id: Jeffrey Creem wrote: > Pascal Obry wrote: > >> Jeffrey Creem a �crit : >> >> >>> I'd certainly be willing to run a few benchmarks but the important thing >>> here is that rather innocent looking code is running 2-4x slower than it >>> "should". >> >> >> >> The first thing is to be sure that we are running the same program. >> >> Running your program with the following changes (as done in Fortran): >> >> 1. Using Sum tmp var for the computation >> >> for I in A'range (1) loop >> for J in A'range (2) loop >> Sum := 0.0; >> for R in A'range (2) loop >> Sum := Sum + A (I, R) * B (R, J); >> end loop; >> C (I, J) := Sum; >> end loop; >> end loop; >> >> 2. Using Long_Float instead of Float (I think Fortran float is a >> Long_Float, to be checked). >> >> I went from 7.8s to 4.8s (with 1) and to 4.2s (with 2). >> >> Pascal. >> > > Actually, the original poster's Ada program had the temp var and all of > my comparisons of programs that I have asserted were "the same" used the > temporary. > > As for Long_Float v.s. Short_Float, gfortran is using 32 bit floats (as > verified by dumping the tree representation and assembly language). > > Since we are all getting a bit confused by specific versions and numbers > I thought I'd post a summary and create a way of tracking more global > performance issues at the gnuada.sf.net wiki. > > The direct link to these test results are here: > > http://gnuada.sourceforge.net/pmwiki.php/Main/Oct2006CLAGFORTRANComparison > > > Actually, as a result of this, I submitted a bug report to the GCC bugzilla list. You can follow progress on it here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543 Interesting initial feedback is that 1) Not an Ada bug. 2) Is a FORTRAN bug 3) Is a backend limitation of the optimizer. Of course, the FORTRAN one still runs correctly so I don't think most users will care that it is because of a bug :)