number crunching

Hi,

I'm looking forward to moving some serious number crunching programs over to Fortran 90/95 from 77. Since they take so long to run (weeks on a fast PC), I'd like to use a pair of dual core processors to spread the work out. MPI would seem the best choice. Is there or will there be such a capability (third party?) for FTN95? Or high performance support? Since you generate coprocessor code (I assume that is 80-bit), I probably don't need 64-bit Fortran but do you expect that at some time?

I've been using Clearwin+ for my interactive programs so it would be nice to stay with the SilverFrost compiler.

thanks

Bruce Weaver

Bruce

There are no plans to extend the capabilities of FTN95 towards MPI or high performance Fortran. Some work has been done on a 64 bit version of FTN95 (i.e. providing a 64 bit address space) but there is currently no firm commitment to deliver this. The best you can get at the moment is a 3GB address space although it may be possible to increase this to 4GB on a 64 bit machine and OS.

FTN95 can deliver 80-bit extended precision real values under Win32 but the limitations of .NET allow only 64-bit real values.

If FTN95 does not provide the power that you require for number crunching, it may still be possible to use it (with ClearWin+) as a GUI front end.

Hi Paul,

I may continue to loosely couple the cpus through occasional data sharing through the disk, which I believe only costs me a couple percent. This is less of a burden than dealing w/ two compilers all the time.

I have no use for .NET nor the 64-bit address space; my concern is with maintaining high precision without a large speed cost. I was thinking I would save a lot by having 64-bit registers. Is this true?

For FTN95 on a current 32-bit processor:

1. how much of a cost is there to load a double or extended precision floating point compared to single ?

2. what variable declarations and/or compiler options must I use in FTN95 to ensure the 80-bit model?

Thanks

Bruce Weaver

In answer to b: In general there are no specific options required, FTN95 performs all internal floating point operations at 80 bit precision. With 80 bit precision it also allows for the use of READ(KIND=3) calculations. There are a couple of options to force precisions namely /DREAL, which forces single precision to double and /XREAL which forces all single and double precision variables to REAL(KIND=3).

Hi all,

Thanks for your useful comments.

I'm still struggling w/ a. Digging around for a few days on the Internet has made things even more confusing since there seems to be every combination of bus widths and register widths and operating system widths. I'm starting to wonder if there is much advantage to going to a 64-bit OS. Apparently not for the calculation part and various processors have various sized registers. How these registers (128-bit, 80-bit, 64-bit, ...) are used (x87, SSE3, ...) is, I guess, up to the compiler. Is the only advantage to a 64-bit operating system, for the purposes of number crunching, fetch speed (if that)?

On the other hand, standard timing tests I did show that a 3 Ghz 32-bit Pentium 4 were not much different than those on a 64-bit Xeon, both running under win2K. So if the caches keep up in 32-bit OS (?), what do I care? Do they? eeeek!

If anyone has some insight or experience in this, it would be greatly appreciated.

Thanks,

Bruce Weaver

Hi S

Since I'll soon be committing to a couple years of developement here, let me be completely sure about what you're saying. The time cost for bringing in a KIND=2 or 3 from memory is comperable between the 32-bit and 64-bit modes for current 64-bit processors?

Memory size is a very long way away for me; my weeks-per-program-run is due to the number of stochastic iterations I must run in a large 2-D space. Although I'd like that space to be much larger, it would require about a year of run time at current one-thread, one-processor mode on a 3Ghz machine; even so I doubt it'd take more than 1 GB.

Bruce Weaver

Bruce

With regard to your question a), modern processors are so complicated that the best way forward is to time a section of your REAL code embedded in a large outer loop so that it runs for at least 10 seconds (say). A comparison could then be made between the run times for REAL4, REAL8 and REAL*10.

REAL*10 will be the slowest.

Hi Paul,

After spending at least 3 days on the Internet trying to sort out the processors and their features, I have come to your conclusion about complexity. Intel in particular seems to have mixed and matched about every possible characteristic. the problem with the testing of my code is that it requires a number of available chip types and transport of the code between different compilers. On the other hand, I need no outer loop as running the code on a small section of spectrum takes about a week on a 3 Ghz Pentium 4.

Initial benchmarks (not my code) comparing a 64-bit Xeon and the Pentium 4 suggest only modest differences. I'm getting a dual core Opteron w/ both 32- and 64-bit Windows to test and I guess I'll have to try a 64-bit compiler as well. I'm completely committed to FTN95, Clearwin+ for my graphical interactive software now (Absoft didn't even have a way to read the mouse) but perhaps this crunching program I'm fretting about will need a different compiler. The only way to know is to do what you are suggesting: buy the compiler and make comparisons for my code.

Thanks,

Bruce Weaver