Newly Updated Polyhedron Benchmarks and Compiler Comparisons - now hosted at fortran.uk

[apple3feet]

I've now completed the latest update to the comparison tables - you can find them at http://fortran.uk.

Some of the changes are:-

* I've used current or very recent versions of the compilers.

* I've removed some "inactive but still available" compilers from the latest benchmark tables, but not from the language and diagnostic charts. There's also a link to historic benchmark tables, so you can still find them there.

* I've updated the harness to deal better with cases where the timings are very variable

* I've added two boxes for F2003 and F2008 support to the Language tables, together with a link to the paper by Ian Chivers and Jane Sleightholme which gives a much more detailed breakdown of support for current standards

* I've added a couple of tests (UIN14 and UIN15) to the diagnostic charts. These tests check whether the compiler can produce executables which identify the illegal use of uninituallized elements in arrays of 2 byte integers and single byte characters. The tests distnguish compilers that use shadow arrays for uninitiallized variable chacking from those that use a special "uninitiallized" bit pattern within the arrays themselves. The latter technique can lead to false positives in one and two byte variables (and, very rarely, for 4 bytes and larger).

Thanks

John Appleyard

[Paul Anton Letnes]

Awesome! I will definitely be using these data points in compiler discussions. It's hard to come by systematic and thorough comparisons like these.

I've got one minor criticism (but I realize it's a debatable point): when reading the autoparallelizing column (intel and absoft), I see that sometimes, execution is slower than in the sequential case. I'd argue that in the overall score (geometric mean) one should use the sequential score, as any half-awake programmer would disable autoparallelization if it does not in fact reduce execution time. But then it's easy for me to redo the math myself in excel, so no big deal.

Thanks again!
Paul

[Wolfgang Kilian]

Nice, there is a check for the detection of dangling pointers. What
about undefined pointers, is that also included?

There are various nasty cases that a compiler might diagnose at runtime,
such as a missing TARGET attribute in the caller of a subroutine.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[Walt Brainerd]

I agree that this is a great resource. Thanks, John.

Silly question: why is gfortran listed under Lahey?
(mainly, it is free, but there are others who sell it).

[Tim Prince]

On 9/17/2015 1:33 PM, Walt Brainerd wrote:

>
> Silly question: why is gfortran listed under Lahey?
> (mainly, it is free, but there are others who sell it).

I suppose it's because that is one version of gfortran which is said to
work with Microsoft GUI.
If Lahey is at all responsible for gfortran becoming compatible with
Windows 64-bit mode, they deserve some credit.

[Walt Brainerd]

By "Microsoft GUI", do you mean Visual Studio?
Yes, that is one option.

But gfortran has worked for years with Code::Blocks and Eclipse
(Photran) on Windows 64-bit systems. It is C::B/gfortran with the
Fortran Tools and I-don't-know-what with Simply Fortran. Why
single out the Lahey system?

I think it would be more reasonable to just test the gfortran
that you can get at Sourceforge (32 or 64).

[FortranFan]

On Thursday, September 17, 2015 at 3:59:43 PM UTC-4, Walt wrote:

> ..

>
> But gfortran has worked for years with Code::Blocks and Eclipse
> (Photran) on Windows 64-bit systems. It is C::B/gfortran with the
> Fortran Tools and I-don't-know-what with Simply Fortran. Why
> single out the Lahey system?

I agree. I increasingly see gfortran as a "reference" and I look to see how much "better" the commercial compilers are compared to this reference.

>
> I think it would be more reasonable to just test the gfortran
> that you can get at Sourceforge (32 or 64).

Can you please provide the link for this? Which one exactly in Sourceforge? I'm not quite sure where the "last good" or even "production" build for gfortran would be among the various things which seem to be available for GCC at Sourceforge.

[Walt Brainerd]

https://sourceforge.net/projects/mingw-w64/files/mingw-w64/

One option on this page is an installer and another
is the source for the latest release and tests. A daily
build (apparently) is

http://sourceforge.net/projects/mingw-w64/files/
Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/5.x/

I have used the stuff I get with the installer for the
Fortran Tools (windows 64). I also have built the source
just for fun, but it took a loooooooooooong time.

I suppose it would also be interesting to know if the Linux
version of gfortran performs any differently from the
Windows (Mingw) version (something for John to do in his
spare time :-). And I would think version 5 would be used
rather than the 4.9.3 in Lahey's system (the FT include 5.2).

[FX]

> Silly question: why is gfortran listed under Lahey? (mainly, it is
> free, but there are others who sell it).

John/Polyhedron is the worldwide distributor for Lahey products. I
personally think that the current presentation is somewhat favoring the
product they sell over the free version. Which is their right, and why we
should treat any vendor-sponsored benchmarks with a grain of salt.

On a related topic, there was a pledge from Lahey to donate part of their
proceeds to GNU Fortran development. As far as I can tell, it has not
happened, nor have they contributed to new feature implementation, bug
fixes, documentation or bug reporting.

--
FX

[FX]

> If Lahey is at all responsible for gfortran becoming compatible with
> Windows 64-bit mode, they deserve some credit.

Nope. Lahey doesn't contribute to gfortran.

The fact that gfortran works well (and has worked well for some time now)
on 64-bit Windows is entirely due to the volunteer work done by two
contributors of the mingw-w64 project, who have developed their runtime,
contributed most (if not all) of the support for GCC, including gfortran.
And have helped (I'm thinking of user "nightstrike" here) when we had
some difficult corner cases to debug and fix.

--
FX

[Gordon Sande]

Perhaps the integeration that Lahey provides is worth the price. I know
that I do
not want to compile all of GCC to get gfortran and I have tried in the past to
figure out just what is needed before I gave up. I would prefer to use a recent
working version at zero fuss to spending my time time as a system
programmer to get
bleeding edge versions (bleeding edge often means with various prolems). I will
do bleeding edge on my stuff but not on tools.

I do numerical analysis and subject matter and am very glad to use the
.dmg zero fuss
versionsion on my Mac even if they are not the nightly builds. I have
an Ubuntu partiton
which I view as requiring more fuss than I care for even though I believe it is
low fuss by Linux standards. I beleive in "It just works" and I tend to not do
large amounts of custonmization so my stuff works just like its manuals.

[Tim Prince]

The most evident performance difference between Windows and linux
gfortran is in the libgomp, which on Windows requires the posix thread
layer on Windows threads, a probable reason for more sluggish
performance and ineffective pinning, even though it has come a long way
recently. I used to make such a comparison on my original core-i7
desktop, but I doubt that remains interesting nowadays when Windows
isn't so often run on the same platforms as linux.
gcc/gfortran/g++ take about 8 hours for a cygwin64 bootstrap build on my
Windows laptop, maybe 2 hours for a disable-bootstrap build. Builds
made with a linux cross compiler seem popular. Testsuite takes over 24
hours (it won't run correctly in parallel) and there seems little
interest in dealing with the issues which are exposed, although the
failure rate is lower for gfortran than other languages, so maybe
someone has looked at it from time to time (or it could just be that
gfortran doesn't have so many features which aren't supported on Windows).

[Richard Maine]

Gordon Sande <Gordon...@gmail.com> wrote:

> Perhaps the integeration that Lahey provides is worth the price. I know
> that I do not want to compile all of GCC to get gfortran and I have tried
> in the past to figure out just what is needed before I gave up. I would
> prefer to use a recent working version at zero fuss to spending my time
> time as a system programmer to get bleeding edge versions (bleeding edge
> often means with various prolems). I will do bleeding edge on my stuff but
> not on tools.
>
> I do numerical analysis and subject matter and am very glad to use the
> .dmg zero fuss versionsion on my Mac even if they are not the nightly
> builds.

I haven't used Lahey in ages (as in well before they adopted gcc), but
this sounds a lot like my motivation for using OS-X back when I still
worked for a living. I had spent inordinate amounts of my time doing
system integration on custom-built Linux boxes for several folk. Once
OS-X came out and sufficiently matured (in particular, once I could get
the NAG compiler and Matlab on Macs), I ended up mostly switching to Mac
desktops. I basically viewed them as Unix boxes where the system
integration work had been done for me. Yes, they cost more in terms of
procurement dollars, but they saved a lot of dollars worth of my time.

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[Steve Kargl]

On 9/17/2015 2:35 PM, FX wrote:
>> Silly question: why is gfortran listed under Lahey? (mainly, it is
>> free, but there are others who sell it).
>
> John/Polyhedron is the worldwide distributor for Lahey products. I
> personally think that the current presentation is somewhat favoring the
> product they sell over the free version. Which is their right, and why we
> should treat any vendor-sponsored benchmarks with a grain of salt.
>

Ah, that explains the choice of command line options. For some
of the benchmarks, the compilers are given -march=native or some
other cpu specific option. The options for gfortran are only
-O3 -funroll-loops. I suspect one might get much better numbers,
if -march=native -mtune=native were used with gfortran.

--
steve

[apple3feet]

Polyhedron was bought out in May 2014, and I've had no financial involvement in Lahey or other compiler sales since then. It's certainly not my intention to favour any particular compiler in this exercise.

I used LGF as a source for gfortran purely as a matter of convenience, and because I might otherwise have been under pressure to run two sets of gfortran benchmarks on Windows.

I'm very disappointed to hear that there was no donation from Lahey - actually it would have come from the company who handled the VS integaration. If you are sure about the facts, I'd be happy to make enquiries.

The compiler options used for gfortran came out of an email discussion I had with Tobias 4 years ago. At that point I tried -march=native, and it made no difference. My usual approach is to use whatever switches the vendor suggests, and to avoid doing experimentation myself.

JA

[vladim...@gmail.com]

Maybe -Ofast instead of -O3 could make a difference? Also, IIRC gfortran also has some autopar capability, but I don't use it because it did not cooperate with OpenMP well and required fixed number of threads at compile-time.

Dne pátek 18. září 2015 10:56:07 UTC+1 apple3feet napsal(a):

[Tim Prince]

On 9/18/2015 5:53 AM, apple3feet wrote:
> Polyhedron was bought out in May 2014, and I've had no financial involvement in Lahey or other compiler sales since then. It's certainly not my intention to favour any particular compiler in this exercise.
>
> I used LGF as a source for gfortran purely as a matter of convenience, and because I might otherwise have been under pressure to run two sets of gfortran benchmarks on Windows.
>
> I'm very disappointed to hear that there was no donation from Lahey - actually it would have come from the company who handled the VS integaration. If you are sure about the facts, I'd be happy to make enquiries.
>

> The compiler options used for gfortran came out of an email discussion I had with Tobias 4 years ago. At that point I tried -march=native, and it made no difference. My usual approach is to use whatever switches the vendor suggests, and not to avoid doing experimentation myself.
>
> JA
>

> On Friday, September 18, 2015 at 5:29:32 AM UTC+1, Steve Kargl wrote:

-march=native will be more important now that you are testing on an AVX
platform and giving other compilers the benefit of it, if you can
upgrade to a more current gfortran.

-funroll-loops unrolls too aggressively for recent Intel platforms. It
should be accompanied by --param max-unroll-times=2 (or 4, as has been
set for PGI). On these platforms, ifort usually improves with -Qunroll4.

I'd prefer not to see standards violating options set such as gfortran
-fno-protect-parens (which appears to have been set implicitly on
Windows but not linux) or the ifort equivalent. ifort no longer needs
the standards violating version of maxloc/minloc, if that is used in
these benchmarks.
Both ifort and gfortran have complex-limited-range set (I don't know
about the others). As this option may easily break an application which
uses complex, full verification is required, and comparison against
compilers which don't use it may be unfair.

[FX]

> -fno-protect-parens (which appears to have been set implicitly on
> Windows but not linux)

Can you explain what you mean? The behavior you describe is not
intentional, and if true, a bug.

--
FX

[apple3feet]

One of the benchmarks uses complex a lot, but all results are checked by our validation program, so, I see no reason to change things.

So.. to summarize, the switches I should use for gfortran are:-

gfortran -ffast-math -funroll-loops --param max-unroll-times=2 -Ofast -march=native

?

If that is agreed, I'll re-run the gfortran benchmarks.

JA

[steve kargl]

apple3feet wrote:

> On Friday, September 18, 2015 at 5:29:32 AM UTC+1, Steve Kargl wrote:

> The compiler options used for gfortran came out of an email discussion I had with
> Tobias 4 years ago. At that point I tried -march=native, and it made no difference.
> My usual approach is to use whatever switches the vendor suggests, and not to
> avoid doing experimentation myself.
>

I see. Then, you may want to add a statement in the NOTES section that
no attempt has been made to find an optimal set of options and the
ones used were (sometimes?) recommended by the vendors/developers.

--
steve

[apple3feet]

I think it would be perverse to go against the vendor's recommendation. In this case, I can see that I should've asked again before now, and I'm trying to put that right. Can you tell me what your current recommendation would be?

JA

[steve kargl]

My personal choice of options are '-O2 -march=native -mtune=native -funroll-loops
-ftree-vectorize'. After seeing Tim's post, I need to re-evaluate the use of -funroll-loops.

Note, I don't use -ffast-math because it can lead to violation of Fortran sematics in
evaluation of expressions. This, of course, means that gfortran will use more
expensive algorithms (e.g., complex division is no longer simple high school math).

Someone mentioned -Ofast. I'm not familiar with the differences between -O2 and
-Ofast. I know -O3 includes expensive optimizations (i.e., longer compile time),
and the resulting executable can sometimes run slower than an -O2 executable.

--
steve

[Thomas Koenig]

apple3feet <apple...@gmail.com> schrieb:

> Some of the changes are:-
>
> * I've used current or very recent versions of the compilers.

I see you used gfortran 4.8.3. This is two major revisions
behind the current released version, 5.2.

[Tim Prince]

Steve's point about -ffast-math is well taken, but gfortran doesn't
abuse the option to the extent that gcc and g++ do. In particular, it
doesn't introduce -fno-protect-parens, although the documentation says
-Ofast will do that. The one objectionable case I have seen is the
transformation A*B + B => (A+1.)*B. A*B + C*B => (A+C)*B is a valid
transformation by Fortran rules (and usually a good one), although it is
one of those things which can make results vary slightly with
optimization level or choice of compiler, as well as having different
(usually better) over/underflow properties.
Without -ffast-math, there is no auto-vectorization (simd optimization)
of reductions such as dot_product, nor of MERGE. Most of the other
compilers have options set to enable such optimization.
The combination -ffast-math -fno-cx-limited-range will cancel the effect
on complex division implementation (and approximates the default of
certain other compilers), but John Appleyard assured us that the results
in this test suite have been checked for correctness under limited-range.
-ffast-math would definitely break some aspects of IEEE_arithmetic.
gfortran -O2 by itself doesn't invoke auto-vectorization, which is a key
aspect of these benchmarks. -O2 -ftree-vectorize is sometimes better
than -O3, and deserves consideration as a production option.
I have encountered failures in gcc/g++ with the combination -O3
-ffast-math -march=native -fopenmp (so have split my sources to avoid
that combination), but recent versions of gfortran have not fallen prey
to those elusive bugs.

[TimZ]

I would like to make some comments on behalf of Marlette Software, the following views are not necessarily those of Lahey or Polyhedron. Marlette creates parts of the software sold by Lahey, including gfortran and the ide.

I think probably the biggest reason that we are included in the benchmarks is that we have "sponsored" gfortran in that we have done a substantial amount of testing both with building compilers and running them on the benchmarks using various combinations of options to heuristically come up with what we consider an optimal configuration for gfortran on Windows. Some of the things we discovered were that enabling fat binaries seems to reliably make small improvements in speed, "-O3 -ffast-math" goes faster than -ofast, and things like autoparallelization and loop unrolling can make dramatic differences in individual tests, but they never seem to improve the overall score. Another thing we discovered is that when comparing our compilers with official builds, there is very little difference, the times posted from our build are also a good representation of what the mingw compilers are capable of. With that said, if someone were to champion the official build in a similar way, and propose a set of compile options, I would encourage Dr. Appleyard to post those results.
Although Lahey does not choose to advertise it, the gfortran that is tested on the Fortran.uk website is free software. Lahey licenses and charges for the ide and support tools, but the gfortran distributions are not restricted or crippled in any way. When the trial period lapses, the gfortran compiler remains fully operational. It can be obtained by downloading trial software, the user may select options at install time to install the compiler only without the ide.
The Lahey gfortran distribution is distinguished from the official mingw version in a couple of ways. We provide bi-arch compiler binaries, it is my understanding that official mingw compilers are usually single architecture. More significantly, we supply debugger binaries built from the archer branch to provide enhanced Fortran debugger support. Last time I checked, mingw debuggers only support F77. Other than that, as the compilers are quite similar, it seems that from the standpoint of making Fortran compiler comparisons, the distribution with better Fortran support is a better candidate for benchmarking.
The pledge to support gfortran comes from Marlette Software, not Lahey. It is Marlette, not Lahey that is remiss here in not making contributions. Regardless of our weak efforts to date, Marlette has best intentions to follow through on its pledge when it is better able to do so.
Polyhedron as FX refers to it doesn't really exist anymore. If you follow the www.polyhedron.com link, you will see no mention of Lahey compilers. Polyhedron Solutions does not sell compilers, and receives no financial benefit from sales of Lahey gfortran products.

Best regards, Tim Z

[apple3feet]

On Saturday, September 19, 2015 at 9:56:46 AM UTC+1, Thomas Koenig wrote:
> apple3feet schrieb:

> > Some of the changes are:-
> >
> > * I've used current or very recent versions of the compilers.
>
> I see you used gfortran 4.8.3. This is two major revisions
> behind the current released version, 5.2.

It's the version that came with the Linux distribution I downloaded and installed in August. In the case of LGF (Windows), I used the current release version.

If I could get a link to a binary version that is agreed to be the current publicly available stable release version for x64 Linux, and recommended switches for best performance, I'm happy to re-run the benchmarks. The links from gcc.gnu.org/wiki/GFortranBinaries have been down for a while...

JA

[Walt Brainerd]

On 9/19/2015 9:28 AM, TimZ wrote:
> website is free software. Lahey licenses and charges for the ide and support tools, but the

The explanation is appreciated; thanks.
That is kind of the way I view the Fortran Tools;
you pay for the installer, books, etc., but gfortran.
Code::Blocks, etc. are included "at-no-extra-charge".

But I am surprised by the comment about the debugger.
The MinGW distribution includes a recent version of gdb.
I have used it only via Code::Blocks, but it does not
appear to complain about "modern" (F90+) Fortran usage,
such as free-format source. The most recent one handles
dynamic (allocatable) arrays, which was not the case a
few months ago.

[Walt Brainerd]

The link to the installer that I posted recently
just now works fine for me from the Wiki page.
(The Windows one.) The installer installs 5.2.

I think others have commented on the options.

[Ian Chivers]

Several people have commented about the version (4.8.3) in the tables,
but I am curious how many currently available Linux distributions come
with gfortran 5.2 installed. How many people use a distro with
5.2 already installed?

[apple3feet]

These switches don't change the overall picture - some benchmarks are faster, others are slower, but the geomeans are not materially changed (23.27->23.95 and 38.36->38.22).

This is with version 4.8.3 on Linux. I can't currently find binaries for a later x64 Linux version. gcc.gnu.org/wiki/GFortranBinaries points to gfortran.com, and that goes nowhere - I get the message

"Changing service providers. New credentials will be required to upload files. Please contact me for info. bdavis9659@......."

JA

[Paul Anton Letnes]

Arch box at home; always bleeding edge. Kubuntu 14.04 at work; it has a package for 5.1 IIRC. The 5.1 is too buggy to compile my current code project though.

[campbel...@gmail.com]

It is good to see some discussion about gFortran.
I have been using mingw-w64\x86_64-x.x.x-posix-seh for the last 12 months and have had good experience testing both vector and OMP instructions. My preferred compilation option has been:
set options=-O3 -mavx -ffast-math -funroll-loops --param max-unroll-times=2 -fopenmp

There are a few alternatives for -march=, which I have not shown to have any significant effect for my testing, including:
set options=-O3 -march=haswell -mavx2 -mno-fma -ffast-math -funroll-loops --param max-unroll-times=2 -fopenmp
This showed little difference, which shows that a preferred option can vary for different types of calculations.

I am using Win 7 on i5 and i7 processors.

The problem I have had is finding a reliable version of gFortran for windows. Gordon Sande suggested, "I do not want to compile all of GCC to get gfortran". The problem I have found is finding a reliable version.
I had been using http://sourceforge.net/projects/mingw-w64/?source=typ_redirect, which others have noted, but was surprised by the recent release version 5.1.0, which included a problem with opening existing files. There was little support provided for this reported problem and also concerning comments from http://sourceforge.net/p/mingw. I am pleased to report that the latest version 5.2.0 appears to have overcome this problem.
My experience has highlighted the question about unknown support and reliability of the variety of gFortran alternatives and especially those for Win_64. There have been other discussions on this forum of upgrading from F77 to F95 and issues of validating code changes to the standard required by (I presume) government contracts, but the issue of compiler validation is a big issue, which I am trying to understand.
I had been using two gFortran sources and testing multiple versions, although both version 5.1.0 had the same bug which I thought should have been picked up in alpha testing.

When I last looked, Lahey LGF - Lassen had not yet progressed to Ver 5.1. I am wondering if that purchase alternative would give some added confidence in bug reduction.

At present, for quality testing, I am still using two old 32-bit F95 compilers, but this approach is limited in the new problems it can test.

I should emphasise, that the development I have done with gFortran has been successful and I am impressed in the ability to test different vector and OpenMP alternatives.

However, the end result is if we use gFortran (or any Fortran compiler) we need to be aware of the quality control of both the compiler we choose and the resulting solutions we develop.

I see a similar problem with established commercial compilers, such as ifort, which have been continually changing with the staged addition of F2003 and F2008 capabilities.

At present, I am uncertain how to manage this problem and would welcome other views.

[Dan Nagle]

Hi,

My $0.02

On 2015-09-19 15:12:22 +0000, Ian Chivers said:

> Several people have commented about the version (4.8.3) in the tables,
> but I am curious how many currently available Linux distributions come
> with gfortran 5.2 installed. How many people use a distro with
> 5.2 already installed?

I maintain gfortran on my employer's supercomputers.

I maintain many revisions but I do have 5.2 on the systems.

I also keep 6.0.x (+ opencoarrays) available so the latest coarray additions
are available for testing.

On the philosophical (?) side, whether or not a distro has 5.2 (or 4.8
or 4.6 or 4.4),
gfortran has been undergoing great advances (Thanks, Guys!) so many
users may be motivated
to upgrade if the distro as downloaded has dated compilers. If I'm
going to upgrade
at all, it would be to the Latest and Greatest. (big) YMMV

Which compiler I really want, if I have a preference beyond L+G,
is likely the compiler my software supplier used to make the software I use.

I may be more motivated to upgrade by the presence of a show-stopping bug
than a really-cool new feature.

>
> On 19/09/2015 09:56, Thomas Koenig wrote:
>> apple3feet <apple...@gmail.com> schrieb:
>>> Some of the changes are:-
>>>
>>> * I've used current or very recent versions of the compilers.
>>
>> I see you used gfortran 4.8.3. This is two major revisions
>> behind the current released version, 5.2.

--
Cheers!

Dan Nagle

[TimZ]

> My experience has highlighted the question about unknown support and reliability of the variety of gFortran alternatives and especially those for Win_64. There have been other discussions on this forum of upgrading from F77 to F95 and issues of validating code changes to the standard required by (I presume) government contracts, but the issue of compiler validation is a big issue, which I am trying to understand.

The fact that the test harness (DejaGnu) uses Linux only features presents a barrier to anyone wanting to run the test suite on Windows. We are experimenting with the version available from msys2, but the environment it operates in is sufficiently different from our build environment so that it doesn't just work as installed.

> When I last looked, Lahey LGF - Lassen had not yet progressed to Ver 5.1. I am wondering if that purchase alternative would give some added confidence in bug reduction.

Since we can't run the test suite yet, we at least make sure that the compiler can build itself. We found the 5.1 compiler was unable to build its own runtime, that prevented it from being a release candidate. We are also starting to build and test numeric libraries - lapack, scalapack with msmpi and slatec. Results from these test suites show that the 64 bit side of 5.2.1 is quite good, passing all tests on the first try. The same can't be said for the 32 bit side, there were failures in all the packages. The 4.9.4 64 bit compiler is not as good, failing some slatec tests. While these sorts of subjective observations are all well and good, we would like to start providing more substantial data on compiler reliability both in the form of our test suite results, as well as providing the user the ability to run the test suites to validate numerical libraries on their own machine.

[Ian Chivers]

The comments that follow are based on information provided
by the people we have worked for directly

•AMEC
•Centre for Ecology and Hydrology, Wallingford
•DTU (Danish Technical University)
•Environment Agency - UK
•Imperial College London
•JET (Joint European Torus)
•King's College London
•Natural Resources Canada
•Petroleum Geo-Services - Houston, Texas
•Petroleum Geo-Services - Weybridge, UK
•PTR - Independent Technical IT Training Providers
•SHMU - Slovak Hydrometeorological Institute
•University of Ulster, Jordanstown, Northern Ireland
•Westland Helicopters

or through third parties.

Aveva
AWE
Esso
UK Met Office
National Nuclear Labs
Qinetiq
RAF
Ricardo Software
Rolls Royce

These people are scientists and engineers
with a job.

Most do not have control of their desk top
(Windows or Linux). some work with gfortran 4.5.x
and earlier versions.

Most do no have the skills or desire to
get involved with computer geeky stuff, or
get paid for it.

trying to install from source gfortran 5 or 6
on a linux distro is not what they get paid for.

Most people we meet are working with compilers, sometimes several
versions from the latest release.

your mileage might vary.

[Paul Anton Letnes]

Dan,

we've got regular desktop/servers with centos 7 and ubuntu 14.04 lts to worry about. Do you have any advice on how to obtain a well maintained newer gfortran? I suspect that, even if I've managed to build gcc from scratch in the past, that my own builds are not as reliable as the alternatives.

I've seen segfaults (on our code, so blocks development) on both OSes for the 5.x packages and the os gcc versions. Otherwise I have the impression that each iteration of gcc brings nice improvements.

Cheers
Paul

[Tim Prince]

Apparently, 5.1 had a serious bug for Windows, which may be fixed in
5.2. I've been testing trunk all along; it seems far more reliable than
available mingw 5.1 binaries.
I run the testsuite once or twice a month on cygwin, and submit the
results. It doesn't work threaded, so it takes over 24 hours. Some of
the continual failures seem straightforward to correct, some may be due
to unsupported features which ought to be accounted for by correcting
testsuite. It's probably possible to use cygwin to run testsuite for
mingw as well as cygwin.
If it's too much trouble to support both 32-bit and 64-bit Windows
gfortran, why not concentrate on 64-bit?

[campbel...@gmail.com]

On Monday, September 21, 2015 at 4:52:48 AM UTC+10, Ian Chivers wrote:
>
> These people are scientists and engineers
> with a job.
>

> Most do no have the skills or desire to
> get involved with computer geeky stuff, or
> get paid for it.
>

I too am an engineer. I get paid doing structural finite element analysis.
To do this better, I am adapting my solutions to 64-bit and incorporating vector instructions and OpenMP so that I can solve more complex problems in a shorter time. With these improvements, then putting the solution inside a few DO loops, I find it amazing what can now be achieved.
It has been interesting doing this work, as I have gained advice from specialists in each field who know much more than I do. My achievement has been to take their advice and combine to achieve a solution. I am not able to keep expanding the umbrella of fields of knowledge to achieve my required solution.

gFortran (with it's many compile options) has assisted me to understand how to do these adaptations. It has taken me a lot of time to achieve this and I don't have the time to spread further into learning how to build gFortran. As an outsider to the GCC project, I found it difficult to know where to look and found the mingw-w64 as a good source of a fully built "gFortran.exe". If some documentation or QA report of testing of these built downloads could be provided, I am sure many like me would be grateful. The range of operating systems that are apparently supported is staggering. It's a great project. I'll take a final build and not go into that paddock!

I can report that the bug I reported in mingw-w64 5.1.0 has been fixed in 5.2.0. I'm not able to comment on the other tests that have been done.

[Thomas Koenig]

Ian Chivers <ian.c...@chiversandbryan.co.uk> schrieb:

> Several people have commented about the version (4.8.3) in the tables,
> but I am curious how many currently available Linux distributions come
> with gfortran 5.2 installed.

I would presume that the number is greater or equal to the number of
Windows distributions that come with Intel Fortran pre-installed :-)

People expect to install commercial compilers themselves. Installing
gfortran is not that much harder.

[JB]

On 2015-09-18, steve kargl <s...@REMOVEtroutmask.apl.washington.edu> wrote:
> My personal choice of options are '-O2 -march=native -mtune=native -funroll-loops
> -ftree-vectorize'.

FWIW, "-march=native" implies "-mtune=native" as well. "-march="
selects both the instruction set extensions (AVX etc.) that are
available as well as instruction scheduling, whereas "-mtune=" only
sets the instruction scheduling. Using both is useful if you want to
produce a binary that will run on some lowest common denominator
architecture (e.g. -march=nocona) but tune for more common cpu's
(e.g. -mtune=generic).


--
JB

[Tobias Burnus]

On Saturday, September 19, 2015 at 7:53:50 PM UTC+2, Walt wrote:
> But I am surprised by the comment about the debugger.
> The MinGW distribution includes a recent version of gdb.

The problem is that GDB does not handle Fortran 90 style arrays (i.e. those with array descriptor). There was some work by Red Hat to implement it (archer branch) and - based on comments of RH's implementor, another implementation by Intel. Part of the latter has been already merged, but the main patch is still missing: https://sourceware.org/ml/gdb-patches/2015-08/msg00143.html

(There are also some follow-up patches in the queue. A somewhat recent version of the Intel patch is nowadays also used by Red Hat's gdb (and hence by Fedora/RHEL and (open)SUSE.)

Thus, if you use an unmodifed GDB, you cannot debug Fortran 90 style of arrays. (Some other improvements of the Archer branch and Intel's work already is in the official GDB. Thus, you will get those.)

Cheers,

Tobias

[TimZ]

> The same can't be said for the 32 bit side, there were failures in all the packages.

To update this comment, I find that when compiled with -msse -mfpmath=sse, rather than the default, the 32 bit accuracy is on par with the 64 bit side.

[John Appleyard]

I've now updated the Linux tables with results for version 5.2.0 of
gfortran, and the geomean times are reduced by around 5% when compared
to version 4.8.3 (23.95->22.94 and 38.22->36.13).

I still can't find pre-built binaries for the latest x64 Linux gfortran
(see below), so I built the compiler from source.

JA

[zmi zmi]

gfortran --version
GNU Fortran (SUSE Linux) 5.2.1 20150721 [gcc-5-branch revision 226027]
Copyright (C) 2015 Free Software Foundation, Inc.

http://download.opensuse.org/repositories/devel:/gcc/openSUSE_13.2/

[FortranFan]

On Thursday, September 17, 2015 at 5:46:10 AM UTC-4, apple3feet wrote:
> I've now completed the latest update to the comparison tables - you can find them at http://fortran.uk.

>
> Some of the changes are:-
>
> * I've used current or very recent versions of the compilers.
>

> * I've removed some "inactive but still available" compilers from the latest benchmark tables, but not from the language and diagnostic charts. There's also a link to historic benchmark tables, so you can still find them there.
>
> * I've updated the harness to deal better with cases where the timings are very variable
>
> * I've added two boxes for F2003 and F2008 support to the Language tables, together with a link to the paper by Ian Chivers and Jane Sleightholme which gives a much more detailed breakdown of support for current standards
>
> * I've added a couple of tests (UIN14 and UIN15) to the diagnostic charts. These tests check whether the compiler can produce executables which identify the illegal use of uninituallized elements in arrays of 2 byte integers and single byte characters. The tests distnguish compilers that use shadow arrays for uninitiallized variable chacking from those that use a special "uninitiallized" bit pattern within the arrays themselves. The latter technique can lead to false positives in one and two byte variables (and, very rarely, for 4 bytes and larger).
>
> Thanks
>
> John Appleyard


Where can one find the source code for all the benchmarks used in compiler comparisons?

[John Appleyard]

On 28/09/2015 22:57, FortranFan wrote:
>
> Where can one find the source code for all the benchmarks used in compiler comparisons?

For the benchmarks, there's a link on the Compiler Comparisons page -
http://www.fortran.uk/fortran-compiler-comparisons-2015/.

For the diagnostic tests, the link is at the bottom of the table.

JA