Bluntly:

nice optimization. But we wouldn't pay for it, yet. (we have the non-commercial trial linux version being a university).

It seems to be designed as a SPECmark compiler, i.e. something to make really fast code on a limited subset of fixed, debugged code, and not really as a generally useful development tool for actual programmers. Oh yeah, its performance kicks ass on the BLAS; the elementary Fortran reference BLAS compiled with ifc and good optimization options seems about on average as good on the LAPACK BLAS benches as an ATLAS blas, which took 8 hours to compile. Nice job.

Why wouldn't I pay for IFC? Because the debugging options are still quite FUBAR, even in the 6.0 compiler. Yes I've submitted bug reports. But still if I compile with -C on, or even some subsets of the -C options after I take off the ones that really mess things up, I am 90% guaranteed of one or more of the following

1) a compiler internal error
2) code that crashes at some point, often the wrong one, and whose stack trace almost always, still, gives "corrupt symbol table" or some equivalent error message, and no indication of the actual source line. More problems persist with the debugger which I have never successfully used to find an actual bug in my code.
3) incredibly slow code with bounds checking, sufficiently slow that I will never get to the point of the error within a reasonable amount of time. It's actually probably a bug as I have waited over 300 seconds with bounds checking on without termination in an attempt to debug to find a crash in an executable run that takes 1 second with optimization, and maybe 5 seconds with NAG with all debugging options on (which actually found the bug).

ifc is the only compiler I've ever used that has fewer internal errors (i.e. outright compiler crashes) with typical optimization options than debugging options. When things are reproducible I try to find a cut-down example but it's hard.

My makefile has optional switches to flip definitions to use either ifc or the NAG compiler that we've paid for. NAG is very reliable and gives correct run-time error messages and almost correct run-time error locations. With maximum optimization it is still not as good as IFC by 15% to 70% but then again a working program is nice.

(I have never found a single significant compiler bug in the NAG compiler in four years)

Honestly, I can't remember ever correctly finding a run-time bug of mine with ifc. I'm sure it has worked once in a while, but now I don't even bother to try, I just flip my makefile to "nag/debugging" and run it again.


I haven't used any other F90 compilers other than NAG and IFC.

As a matter of curiosity, are the problems with the debugging options specific to Linux?

I mean I can't imagine a compiler getting to a supposed 5.0 or 6.0 version with as many bugs as I saw in the -C options, and so I presumed it was for many years a windows only compiler and thus the port to Linux is still new.

Actually, I am not even talking about debugging with a debugger. (That has always been so problematic I never bother).

I am talking about the run-time checking options activated with -C. Fortran 95 is so much better than C++ in this regard because the language actually knows and defines things about allocations, pointers, and array bounds. But it is completely useless for me on IFC.

The stack trace it prints out is almost always "corrupt" and hence prints out no line number information which is precisely what you want. Othertimes it incorrectly dumps run-time errors when there aren't any. And finally I have gotten actual compiler core dumps though with the latest versions these seem to be less frequent.

Yes, I have submitted bug reports for all of these. The first one is still active seven months on. Look up 106222 and tell me if isn't a really silly bug.

Getting a full-on debugger working is a big task----I would much strongly prefer that the run-time error-checking is made bulletproof first. Few of my fellow scientists are likely to use a debugger, and all of them are likely to use run-time error messages. Frankly when they work correctly (with the NAG compiler we have a license for) there is infrequent need for a debugger.

Also, I was going to try to post this to the "access problem" section---- i am having great difficulties accessing this forum from Linux browsers. Frequently things hang, and other times when I select a forum nothing but a microscopic icon of a folder or a bullet-point comes up. I have tried this with Mozilla and Opera.

Frustratingly enough, this happens much much more often with the "Linux Fortran" forum than the "CVF" or "Pentium" forums.

Steve,

Well, it's a lot better than previous versions! I think it has a way to go though. Some specifics:

1. There needs to be better control over warnings. We've discussed this, and I mentioned it during the beta. When you have a large team working on codes that are typically 250000+ lines, it's just not reasonable to wade through thousands of warnings about comment lines longer than 72 characters to find the few warnings that really could indicate a problem. The level of some warnings should be reclassified, and users need more control over what warnings come out (for example, turn off only certain warnings).

2. On paper, -C is an incredibly powerful, useful option that would really be a selling point for this product. In practice, it routinely blows out the memory on our 768Mb machines before the compile completes.

3. The lack of buffered I/O clobbers performance in some situations (some really important ones for us).

4. We're still having a problem with one of our codes in which performance is hundreds of times worse than with Portland Group. The Intel-compiled code spending all if its time doing I/O (virtually no CPU). ptrace suggests the I/O library is doing a write(), then seeking back to the beginning of the write, then redoing the write(), several times in a row. Premiere support requested a simple test case, and of course we haven't been able to duplicate it with any small piece of code. My guess is that the FORTRAN I/O library is getting confused somehow (possibly our fault), but I don't think we're going to be able to solve this unless someone at Intel eyeballs the code for the FORTRAN I/O library to see how it could be getting into this write/seek loop.

5. Parallel compiles need to be supported. This problem is exacerbated by the fact that Intel 6 is much slower than others. This would be ok if we could compile in parallel though.

On the good side, we're getting good performance improvements for some codes on Xeon, and the front end seems to do a good job of error checking. Until we can get all of our primary codes running well though (#4 is the showstopper, we'll stick with our existing compiler.

Thanks,

Pete Bradley
Pratt & Whitney

Steve,

Yeah, I know this is a tough one. We can't come up with a cut-down case, it's hard to debug it based on our limited information. What we know so far:
- Normally compute-bound program is totally I/O bound
- WRITE(6, *) statments (redirected to a file by run command) are generating looping write/seek behavior
- Cut-down programs (and another closely-related large code) do not show the behavior
- Optimization flags have no impact. -C90 has no impact

Any suggestions for narrowing it greatly appreciated.

Regarding -C, the run-time checks sound really great, they just need some more cleanup work. I hope Intel will continue to pursue this. The Achilles heel of this option right now is large (1000+ lines) ugly subroutines, exactly the code they would be great for.

Thanks,

Pete

About the weird I/O program. All I can imagine is an array bounds violation that is occasionally overwriting some sort of I/O control list. (I don't know anything about the internals so I don't know much.) That's usually the answer I've found for very weird intermittent bugs that disappear upon cutting down the program.

This is why having good -C checking options working is very important, as well as the option to automatically initialize things to NaN unless explicitly specified.

Do you have another compiler to try it on that has good checking options?

Got another user who's been using -C to clean up an old program. He really loves it, and the program is small enough to avoid the memory blowouts that we've seen with -C on larger codes. This is definitely a great feature, and one that will be even more attractive if it can handle really huge ugly code.

Thanks,

Pete

I am fond of Fortran 9.0, because it is old and new together and I can write quick and short programs, that are easy to read and understand for everybody.Only one problem: how to use 30 real-time signals in the situation, when in Russia practicaly no docs devoted to this problem. 25 years ago I wrote real-time systems using only 1 signal without any OS.

Sahalinzud

Our group uses Intel Fortran at a University and we are very grateful for
such a superb product. Specially Fortran 9.1 and its support for OpenMP.
I use Linux on new intel machines. My latest is the Core 2 Extreme and
running OpenMP for my very large reaction code. We have accounts on
various supercomputer sites and I could never take full advantage of their
multi processor systems properly. My code is such that it can do much better
with OpenMP than MPI but only if I can use REDUCTION on arrays etc.
Intel Fortran 9.1 have been working flawlessly.


I can't wait to order my Core 2 Quad system!
Thanks
S. Umar

Steve,

I've seen a similar write problem on Windows. When I emit diagnostic messages into an audit trail file:

OPEN (IOUERR, FILE ='GERROR', STATUS='UNKNOWN')
...
WRITE(*,*) 'message', values
WRITE(IOUERR,*) 'message', values

I write to console window as well as audit trail file. About half of the writes are formatted.

The larger the audit trail file gets, the slower it runs. The behavior is as if there is a rewind then sequential search of record markers to findend of file. Just a guess, as I have not examined this to find out whatactualy is happening. Most of the time the audit trail loging is off - so this hasn't warrented much investigation time.

Jim Dempsey

Hi all,

we use mainly the Intel Fortran compiler (currently 9.1), but also the NAG f95 and gfortran compiler. Plus in the computation centres the compilers available there (e.g. Pathscale or the Portland Group compiler). Primary platform is Linux (mostly AMD64, some Pentium* and Intel64).

In general, I'm happy with ifort. It is rather fast (though I wished it would be a bit faster, especially on Opteron (cf. e.g. the Polyhedron tests: [Pentium D820] [Opteron]). Compared with other compilers, it supports also already some Fortran 2003 features. (NAG f95 is still unbeaten in this regard.)

The debugging possibilites are rather nice (especially with -gen-interface), though some further checking would be nice. NAG f95 is much better in this regard (call checks, initialize reals with signalling NaN, etc.)
These are also some, which could then be found in the Polyhedron's diagnosis test.

I currently miss some Fortran 2003 features, some of which are in ifort 10, I presume. Especially, the ISO C Bindings and IEEE support are missing, plus some smaller things.

Well, I forgot to mention for what the compiler is used: Electronic structure calculations programs. These are mostly Fortran 95 programs (Wien2k, Fleur, Exciting, Octopus); in addition, I use a bigger FORTRAN 77 program and some smaller auxilary programs which use e.g. the command-line feature of Fortran 2003.

Tobias