forums.silverfrost.com

[DASwainEsq]

We're having a strange problem with a program running much slower with the latest salflibc.

I can find no Fortran reason for a long standing program to run substantially slower than before - a run that in earlier compilations takes a minute to run, now takes 20 minutes to complete. However my colleague (the author of the original code) compiles erstwhile the same program on an earlier version of Silverfrost, so I randomly tried running the executables with the salflibc contemporary with his older compiler.

If we refer to my work as New compiler (v9.10) and the dll provided with that compiler as New salflibc - and similarly Old for the pair of items, we get the following run times, (running the same test on the same machine).

Version New compiler Old Compiler
New salflibic 24.27 mins 26.04.mins
Old salflibic 1.12 mins 1.11 mins

So the problem appears to be associated with the new salflibc?

The only remarkable feature about the program in the erea where the delay accumulates that it is using a SCRATCH DIRECT ACCESS FILE.

[I know I used to avoid such files 45 years ago on IBM 370 mainframes, as they were slow - every record generating an "exception" to be handled - but this is the first time I've seen a similar phenomena under Windows}

Can you check whether something has changed in the salflibc etc...

David Swain

[PaulLaidler]

I doubt that there has been any related change to salflibc.dll. Are you using the same version of Windows?
You could test by copying the DLL (after creating a backup). Versions of salflibc.dll are sometimes interchangeable. 9

[DASwainEsq]

Paul - that's exactly what I have done - same machine, same operating system (23H2) - same executables, just changed salflibc. - David

[PaulLaidler]

David

There has been a change in order to provide for access to records with size greater than 2GB. I can't see that it would affect your code but if you can send me a working sample then I will aim to investigate further.

[DASwainEsq]

Paul

Thanks.
Would current executable and input data initially suffice? Because it's a scratch file and deep inside the code, not easy to quickly generate a simple realistic example?

[PaulLaidler]

David

I would need the code in order to step through it a then see how it uses the library.

[DASwainEsq]

OK - it might go a little quiet from my end while I sort out what I can send.

The fix for the short term seems to package in the older salflibc.dll with our programs, which reduces the immediate pressures on me.

[wahorger]

Just a side note: I found that McAfee Anti-Virus would "get in the way" of FTN95 executables. This began occurred last year. I had to turn off executable scanning. One of the AV processes would start consuming enough CPU to hang up 2 processors for up to 3 hours, sometimes more, unless manually terminated. It was bizarre. I could repeat it on a different machine as well.

I turned it back on with the latest version (9.14) because whatever was causing the bad interaction was no longer present.

FWIW, I can actually see the AV software slowing down my rebuilds as it examines each executable (and DLL) each time a program is run in my MAKE file (i.e. FTN95, SLINK, ...).

Here's the message I sent my users in September 2024. It addresses two "occurrences" that may or may not be related.

[PaulLaidler]

If it is a virus checker issue (McAfee or other) then we would not be able to fix it. It would be an issue for the provider of the virus checker.

[DASwainEsq]

Just so we are not distracted by the "side-note", the Direct Access run time issue is not a McAfee Anti-Virus problem - David