This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dragonegg in FSF gcc?
On Wed, Apr 14, 2010 at 12:57:41AM +0200, Steven Bosscher wrote:
> On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth <howarth@bromo.med.uc.edu> 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).
>
> 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.
>
> Can you point out some postings where people actually made a
> comparison between GCC and LLVM with DragonEgg?
>
>
> 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.
>
> 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.
>
> 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...
================================================================================
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 induct 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 = 11.27 seconds
================================================================================
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
>
>
> > ? 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.
>
> 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.
>
> 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.
>
> Ciao!
> Steven