Prev: Why was SPREAD left out of initialization expressions?
Next: Compile and link optimization using gfortran
From: Tim Prince on 22 Jun 2010 08:48
On 6/21/2010 11:30 PM, Philipp E. Weidmann wrote:
> Mike Prager wrote:
>> I am in the market for a single copy of a commercial* Fortran compiler
>> to use under Windows. I'm seeking advice on the options.
>>
>> Because I am a one-man, part-time consulting shop, price is important.
>> Lahey Express is cheap, but apparently it's not being updated any
>> more. Intel and Absoft both seem good and current. Absoft is a bit
>> cheaper, and from what I can see, it is fast and complete. However,
>> its diagnostics aren't so great. On the other hand, its IDE was
>> designed for Fortran, which would be a pleasant change -- I don't much
>> care for Visual Studio.
>>
>> Any comments on these or other suitable compilers -- including
>> comments on tech support -- would be helpful. Feel free to send them
>> by email if you would rather comment privately.
>>
>> Thanks!
>>
>> Mike Prager
>>
>> * I am looking only at commercial products because none of the free
>> versions has an option (like Lahey's vsw or Intel's QuickWin) that
>> makes a simple Windows program without coding changes. If I'm wrong
>> about that, it would be great to know it. I have considered using
>> DISLIN's widget routines, but that is a much more complex approach.
>
>
>
> I use Intel myself, and find it a very good compiler with many
> diagnostic options. On Windows, it comes with an IDE based on Visual
> Studio which tightly integrates with the compiler, exposing all switches
> directly through the GUI.
>
> However, I also like gfortran a lot, and the truth is that this free and
> open source compiler is probably sufficient for almost all projects,
> commercial or otherwise. One strong point of gfortran is the ability to
> use the C preprocessor of the GNU Compiler Collection in your Fortran
> projects, which can be *very* useful.
>
ifort, like all compilers with OpenMP support, includes an fpp
pre-processor. In addition, we often see Makefile set up to use gcc as
a pre-processor for ifort or pgfortran. Yes, even on Windows.

Aside from Ian Chivers' useful rehearsal of the usual comparison sites,
it seems that application performance isn't much of a consideration in
this thread.
The compilers which show up well on the Polyhedron benchmark have made
special efforts to do so; likewise, several commercial compilers are
specially tuned for SPECfp and SPEComp. In my experience, Fortran 95
array assignment optimization tends to be the stronger point of
gfortran, while ifort and pgfortran excel in f77 optimization with
multiple assignments per loop. OpenMP performance isn't covered in as
useful a way by the comparison sites; gfortran has come up to the top
rank for OpenMP performance on linux, but not Windows.

--
Tim Prince
From: Ron Shepard on 22 Jun 2010 11:05
In article <88bpogFiaeU1(a)mid.individual.net>,
Tim Prince <tprince(a)myrealbox.com> wrote:

> > However, I also like gfortran a lot, and the truth is that this free and
> > open source compiler is probably sufficient for almost all projects,
> > commercial or otherwise. One strong point of gfortran is the ability to
> > use the C preprocessor of the GNU Compiler Collection in your Fortran
> > projects, which can be *very* useful.
> >
> ifort, like all compilers with OpenMP support, includes an fpp
> pre-processor.

Practically speaking, that is almost irrelevant at the present time.
The important feature that is used by many codes is the use of the C
preprocessor. As with most other fortran compilers, ifort uses the
C preprocessor automatically with upper case file extensions (*.F
and *.F90 for fixed-format and free-format source code respectively).

I don't know when (or if) the fortran preprocessor will ever become
as popular as the C preprocessor for fortran code. The demand was
so great in the 1980s for a standard preprocessor that something had
to step in and fill that need. cpp has problems, but it could be
made to work. Other possibilities, such as m4, had other
liabilities. And the fortran standard committee refused to take
action in a timely manner, so cpp stepped in and now there are
probably hundreds of millions of lines of fortran code that use cpp.

Of course, if you have one of the rare codes that use the fortran
preprocessor, then that is an important feature in a compiler for
you. But those are, at present, rare codes.

> In addition, we often see Makefile set up to use gcc as
> a pre-processor for ifort or pgfortran. Yes, even on Windows.

For compilers that do not support cpp automatically, another option
is the separate filepp. This is a perl script that is quite capable
and flexible. And you have the source code if you want to change
something. It has all the functionality of cpp, plus some more
powerful programming constructs, such as the ability to set up a
loop to generate blocks of code.

I wrote and maintained my own conditional compilation utility for
about 15 years in the 80's and 90's. I was in a holding pattern
waiting for the fortran committee to act. What I thought was a
short-term fix ended up lasting much too long. If I had known what
was going to happen, I would have switched to cpp (or something like
the filepp perl script) a decade earlier and just moved on.

$.02 -Ron Shepard
From: Tobias Burnus on 22 Jun 2010 11:29
On 06/22/2010 05:05 PM, Ron Shepard wrote:
> In article <88bpogFiaeU1(a)mid.individual.net>,
> Tim Prince <tprince(a)myrealbox.com> wrote:
>
>>> One strong point of gfortran is the ability to
>>> use the C preprocessor of the GNU Compiler Collection in your Fortran
>>> projects, which can be *very* useful.
>>>
>> ifort, like all compilers with OpenMP support, includes an fpp
>> pre-processor.
>
> Practically speaking, that is almost irrelevant at the present time.
> The important feature that is used by many codes is the use of the C
> preprocessor.

I think there is a language problem: There is the conditional
compilation as defined in part 3 of the Fortran 95 standard (ISO/IEC
1539-3:1998); I think almost no one uses this one and I do not know any
compiler supporting it. If one needs it, there exists the preprocessor
coco at http://users.erols.com/dnagle/coco.html

But FPP and CPP are used somewhat interchangeably: Both mean the C
preprocessor, possibly adapted a bit for Fortran (and thus called fpp);
depending on the compiler cpp/fpp might not use not the full C99 feature
set and might (or might not) be adapted for Fortran. Cf. fdfpp at
http://www.netlib.org/fortran/

Talking about CPP: The problem with a true "C" cpp (such as the one that
ships with GCC) is that it does not know about Fortran; thus
! It's important
will print a warning because of the single quote - as the compiler does
not recognise the comment. For that reason, gfortran uses CPP (libcpp)
in the traditional mode (which disables some nice C99 CPP features).
Other vendors (e.g. Intel) have updated their internal preprocessor to
know about Fortram. (Which is also planed for cpp / gfortran -cpp but no
one is currently working on it.)

As the kind of preprocessing supported by the Fortran compiler is a bit
unpredictable, there are programs - as mentioned by Tim - which indeed
call (the GNU) "cpp" explicitly, even though the build-in CPP/FPP of
most Fortran compilers would simply work.

Tobias
From: Ron Shepard on 22 Jun 2010 12:17
In article <4C20D6F6.6050009(a)net-b.de>,
Tobias Burnus <burnus(a)net-b.de> wrote:

Ok, if the fpp mentioned was not the fortran preprocessor, then my
comments were misdirected. Hopefully they were still useful, or
perhaps my confusion was entertaining, nonetheless.

> Talking about CPP: The problem with a true "C" cpp (such as the one that
> ships with GCC) is that it does not know about Fortran; thus
> ! It's important
> will print a warning because of the single quote - as the compiler does
> not recognise the comment.

Yes, there are other problems too. I don't remember exactly the
character sequence, but I remember getting in trouble in a fortran
code that had a # within a character string. This somehow triggered
something unexpected in the C preprocessor and it took a while to
figure out what was happening. Maybe this was related to trigraphs
in C, or cpp macro concatenation or something, I forget the details.
There was an easy work around once the problem was identified, the
problem was that I was a fortran programmer trying to figure out how
some obscure feature of C syntax was affecting some otherwise
perfectly legal fortran code.

The fortran standards committee did a true disservice to fortran
programmers in the 80's. Even now, almost 30 years later, as
evidenced by this thread, that plague is still visiting our houses.

$.02 -Ron Shepard
From: Gary L. Scott on 22 Jun 2010 20:18
On 6/22/2010 11:17 AM, Ron Shepard wrote:
> In article<4C20D6F6.6050009(a)net-b.de>,
> Tobias Burnus<burnus(a)net-b.de> wrote:
>snip
> The fortran standards committee did a true disservice to fortran
> programmers in the 80's. Even now, almost 30 years later, as
> evidenced by this thread, that plague is still visiting our houses.
>
> $.02 -Ron Shepard

COCO???

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Why was SPREAD left out of initialization expressions?
Next: Compile and link optimization using gfortran