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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!postnews.google.com!k70g2000cwa.googlegroups.com!not-for-mail From: "Alinabi" Newsgroups: comp.lang.ada Subject: Re: GNAT compiler switches and optimization Date: 22 Oct 2006 06:50:13 -0700 Organization: http://groups.google.com Message-ID: <1161525012.997046.264780@k70g2000cwa.googlegroups.com> 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> NNTP-Posting-Host: 68.235.169.69 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1161525018 11445 127.0.0.1 (22 Oct 2006 13:50:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 22 Oct 2006 13:50:18 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.7) Gecko/20060921 Ubuntu/dapper-security Firefox/1.5.0.7,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: k70g2000cwa.googlegroups.com; posting-host=68.235.169.69; posting-account=gD74RA0AAABm9rsBG7oeOmJ-iO5c3KUQ Xref: g2news2.google.com comp.lang.ada:7131 Date: 2006-10-22T06:50:13-07:00 List-Id: I ran your test programs compiled with gcc 4.0.3 and the following optimizations: COMMON_FLAGS=3D-g -march=3Dopteron -mtune=3Dopteron -mfpmath=3Dsse -fomit-frame-pointer -O2 -fdump-tree-optimized and I cannot reproduce the large differences in performance everyone else talks about. Here are the times I get: N Ada Fortran =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 64 0.002029 0.000000 128 0.016321 0.016000 256 0.214143 0.204013 512 3.125888 3.124195 800 6.374982 5.864366 1024 34.10479 35.22620 2048 277.3071 283.2417 Jeffrey Creem wrote: > Jeffrey Creem wrote: > > Pascal Obry wrote: > > > >> Jeffrey Creem a =E9crit : > >> > >> > >>> I'd certainly be willing to run a few benchmarks but the important th= ing > >>> 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 :=3D 0.0; > >> for R in A'range (2) loop > >> Sum :=3D Sum + A (I, R) * B (R, J); > >> end loop; > >> C (I, J) :=3D 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/Oct2006CLAGFORTRANCompari= son > > > > > > > > > > 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=3D29543 > > 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 :)