From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23160 invoked by alias); 13 Apr 2010 23:11:30 -0000 Received: (qmail 23150 invoked by uid 22791); 13 Apr 2010 23:11:28 -0000 X-SWARE-Spam-Status: No, hits=1.0 required=5.0 tests=BAYES_50,TW_DB,TW_EG,TW_LV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 13 Apr 2010 23:11:23 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id 038D2B0061; Tue, 13 Apr 2010 19:11:21 -0400 (EDT) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id o3DNBKsh027994; Tue, 13 Apr 2010 19:11:20 -0400 Date: Tue, 13 Apr 2010 23:43:00 -0000 From: Jack Howarth To: Steven Bosscher Cc: Duncan Sands , gcc@gcc.gnu.org Subject: Re: dragonegg in FSF gcc? Message-ID: <20100413231120.GA27928@bromo.med.uc.edu> References: <20100409163655.GA25781@bromo.med.uc.edu> <4BBF5B7C.7060801@starynkevitch.net> <4BC07718.3060400@free.fr> <20100411141702.GA8481@bromo.med.uc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00313.txt.bz2 On Wed, Apr 14, 2010 at 12:57:41AM +0200, Steven Bosscher wrote: > On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth = wrote: > > Rather than viewing dragon-egg as some sort > > of lamprey which is feeding off of the FSF gcc project, > > we should welcome the competition from a direct comparison > > of alternative back/middle ends (not fear it). >=20 > FWIW, this sounds great and all... but I haven't actually seen any > comparisons of GCC vs. LLVM with DragonEgg. A search with Google > doesn't give me any results. >=20 > Can you point out some postings where people actually made a > comparison between GCC and LLVM with DragonEgg? >=20 >=20 > However, I found your posting of "llvm-gfortran" Polyhedron > comparisons of different LLVM versions > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-April/030799.html). > But that comparison does not including gfortran results. >=20 > I also found comparisons of llvm-gfortran and FSF gfortran > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-June/015441.html and > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025119.html). > But unfortunately I can't find these results posted on the GCC fortran > mailing list, or Bugzilla bug reports for cases where llvm-gfortran > performed better than FSF gfortran. So there's not much benefit from > these comparisons for GCC. >=20 > Where these results generated using DragonEgg? Or can you make these > comparisons without DragonEgg too? Those benchmarks were made with just the stock gfortran from the llvm-gcc-4.2 source tree from the release_27 branch. Of course, the benchmarks for gcc 4.5 (or gcc 4.4) are signficantly faster (gcc 4.2.1 isn't the best release to be trapped on for gfortran performance). On the same machine, I am seeing these numbers for the gcc 4.5 release... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Date & Time : 25 Mar 2010 0:08:05 Test Name : gfortran_lin_p4 Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o = %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn indu= ct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats : 10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- ------- ---------- ------- ------- ------ ac 0.86 10000 10.59 10 0.0069 aermod 39.15 10000 21.35 10 0.0086 air 2.24 10000 5.68 12 0.0392 capacita 1.70 10000 33.19 10 0.0110 channel 0.56 10000 1.83 10 0.0257 doduc 4.58 10000 27.72 10 0.0122 fatigue 1.54 10000 8.04 10 0.0382 gas_dyn 2.83 10000 4.39 18 0.0965 induct 3.55 10000 12.67 10 0.0127 linpk 0.70 10000 15.41 10 0.0458 mdbx 1.51 10000 11.33 10 0.0059 nf 1.90 10000 27.96 17 0.0967 protein 3.48 10000 37.02 10 0.0058 rnflow 5.20 10000 23.64 10 0.0243 test_fpu 4.19 10000 8.68 10 0.0494 tfft 0.49 10000 1.88 10 0.0766 Geometric Mean Execution Time =3D 11.27 seconds =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D I intend to do some benchmarks with dragon-egg shortly. At the moment, I am finishing up a gcc45 fink package capable of building dragon-egg. My goal is to have fink packages for gcc45, llvm-2.7 and current dragon-egg so that everything can be tested against the other. My current plan is to have compiler wrappers, degcc-4, etc, which will automatically call the plugin. It will be particularly interesting to see how dragon-egg manages libLTO usage. Hopefully by gcc-4.5.1 we will have the Mach-O LTO working and some direct comparisons can be made between the two. Jack >=20 >=20 > > =A0 One could also make an argument that it is in the best > > interest of FSF gcc to do so. Isn't better to keep all > > of the alternative front-end developers (gfortran, ada, > > etc) within the FSF gcc tent rather than forcing the > > creation of competing clang fortran and ada projects. >=20 > Why would that be better? And, why would that be better only for the > front ends, but not for the middle ends and back ends? You don't seem > to have a problem with the creation of competing back ends. If you so > believe in competition between compilers, then why are you against > competition at the level of front ends? You should encourage a clang > fortran project. >=20 > But apparently, you don't. That doesn't look like a desire for > competition or comparisons, but only a desire to rip the parts of GCC > that LLVM doesn't already provide itself. >=20 > Ciao! > Steven