forums.silverfrost.com

[PaulLaidler]

Please note that 64 bit FTN95 is not expected to be fast at this point in time.
Standard optimisation and then /opt will come in due course but /opt may not be available in the first full release.

[mecej4]

John, thanks for verifying the run times with FTN95-64. Knowing that I should be sparing in asking someone else (with access to FTN95-Beta-3) to run tests for me, I deliberately picked a combination of parameters in your test code where FPE was a severe bottleneck, recognizing well that the combination could be a poor choice for the real problem of solving banded linear equations.

The performance with /64 already puts FTN95 back in the game. As Paul points out, /64 will preclude /opt for a few months, so there is something to look forward to. That a beta release enabled us to compile your test code (and run with no errors, with speed comparable to other production compilers') seemed worthy of applauding.

Do you have any explanation as to why underflow is so frequent in these tests? Until we had irrefutable evidence of that, I had no clue that it would be anything but a rarely occurring event.

[JohnCampbell]

Mecej4,

Since you pointed out the problem, being fpe, I have included the fpe count reporting in my FE analysis program and there have been very few occurrences. The occurrence of the underflow in the test program has been more a poor design for the test matrix in profile.f90, where I had looked for a density and profile to drive the operations count.

My experience of FTN95 /64 is that I am very impressed with the general performance. I have tested Beta_1 and Beta_2 and after a couple of isolated problems, both produced .exe that worked well. I am now using my clearwin+ program in production mode and would not return back to /32. I got all programs I tested to run correctly with Beta_1 and have been able to remove most patches I did when Beta_2 was released. I shall test Beta_3 shortly. I have had a number of problems with file I/O buffering and automatic arrays, but none with large arrays. My big memory tests worked first time! (It would have been good to see the bug reports for Beta1 +). As I've mentioned a number of times, the implementation of COMMON should be a big plus for expanding old programs.
CODE/EDOC is not available as yet, which hopefully will come soon, and with SSE being available.

I am also using Beta_2 for /32 programs, with no identifiable problems.
(I actually spent yesterday searching for a "bug" in FILES@, which was reporting the wrong date stamp for a file, only to later find the file as:
c:\Users\Campbell\AppData\Local\VirtualStore\Program Files (x86)\Silverfrost/ftn95.cfg. Somehow Windows 7 has changed the protection in \Silverfrost\FTN95 !!)

I hope Dan tries it out soon, as all the memory squeeze type bugs disappear with /64, and old style debugging is not that hard.

John

[PaulLaidler]

John's observation about FTN95 configuration files prompts me to provide some details about "FTN95 /config".

The command line options for FTN95 can be configured via "FTN95 /config" and the resulting ftn95.cfg file can be placed alongside FTN95.exe (to be applied to all compilations) and/or in the local folder (to be applied to the local project).

This was quite useful in times past before IDEs became available but can be problematic when used with an IDE. Even when using a batch file approach, the use of a ftn95 configuration file can have its problems.

This has become a more serious issue with Windows Vista, 7 and 8 (and maybe 10 also) where Microsoft has blocked normal access to the "Program Files" folder. So if FTN95.exe is located in its default folder, you will not be able to put ftn95.cfg alongside it without elevating to administrator privileges. Unfortunately Microsoft doesn't usually give a failure message but puts the file in "Virtual store" instead. Then FTN95 does not know to look there for the configuration file.

All of this means that in today's world ftn95.cfg files are probably more trouble than they are worth.

In the current beta release of FTN95 and the next full release, "FTN95 /config" has be modified so that you are now prompted to elevate to administrator privileges when you come to save ftn95.cfg. In addition a new option "FTN95 /cfg" has been added for when you want to save ftn95.cfg to the local project folder.

This modification may ease the problems but I would recommend that users of Plato and Visual Studio avoid using FTN95.cfg. Even those who use a batch file approach might find it easier in the long run to list the options in the batch files rather than use FTN95.cfg.