forums.silverfrost.com

[wahorger]

Just to be clear, using RAMDISK, while exceptionally fast, is not what is being measured. The measurement has to take into account the real world situation that seems to affect the speed, namely using a hard drive. If I was writing a huge number cruncher with vast arrays stored on disk, I'd certainly use RAMDISK!

As John and I have found (perhaps others?), there is something going on. It's not a reflection on FTN95; some folks don't appear to have this issue. Rather, it is an interaction between good/decent code and the OS (so far, WIN7, XP, Win2K on my side). As I also pointed out, if I use my local network to perform these simple benchmarks, I see no major speed issues (there is a little something there, though).

[mecej4]

[JohnCampbell]

mecej4,

I agree with your changes 1. and 2. but I disagree with change 3. ( I'd recommend elapsed rather than CPU time)

I also changed the timer I posted to correct real*4 precision problems as:

[mecej4]

John, the main reason that I turned from SYSTEM_CLOCK to CPU_TIME was that, with your old ELAPSED_TIME function, Intel Fortran gave zero elapsed time for many of the runs, indicating that 23 bits (in REAL*4) were not enough to hold elapsed time. I reran with your new code for ELAPSED_TIME, and the results are hardly different (comparing FTN95 run to FTN95 run and IFort run to IFort run).

The laptop on which I run these tests is an Ultrabook with 4G of RAM, Norton Security Suite, and has an internal 128 GB SSD, with the power plan set to Balanced. The only way to connect a conventional HD is through USB 2/USB 3 or Wifi, and using such a HD would give results that are probably not useful to most people who have other hardware.

If you suspect that your anti-virus software is affecting the results, you could disconnect from the network, disable the anti-virus, run the tests, and reenable the anti-virus before reconnecting to the network.

[JohnCampbell]

Mecej4,

[mecej4]

[wahorger]

Regarding use of RAM Disk vs. HD:

Here is some data taken using my old test code without the generation of random data (not your new stuff John) run on the HD vs. the RamDisk. Clearly, the elapsed time is greater on the physical drive, but not by much. Except for those DIRECT UNFORMATTED write operations with SHARE=COMPAT , DENYRD and DENYNONE on the HD. In those cases, the HD access time stands out!

Notice that while the elapsed time for RAM Disk is fast, there are significant differences in time even then and under the same conditions as the HD times. This would indicate that additional time is being consumed doing an electronic version of what the HD is doing physically. Just doesn't take as long.

[JohnCampbell]

These are the results taken from a pivot table summary from my latest program which includes elapsed and cpu time reports.

[wahorger]

John, yes, I am avoiding the "bad boys". Right now, I'm still performing conversion tasks on the software, bringing it in line with FTN95, and testing it thoroughly.

And, having said that, I'm putting this issue on my back burner. While I think this is important to understand, there's a limit to how deep down the rabbit hole I'm willing to go; there's only so much time with which to put out a product.

I am hoping that, sometime, there will be a root cause explanation, either one that offers a solution (like a policy setting), or, perhaps, something in the run-time system that needed a tweak and has now eliminated the problem.

If that doesn't happen, at least there is a workaround, and for that, I am grateful to the group here for answering my posting, and for asking more questions and offering things to try, and for taking to "play" with settings.

Bill

[JohnCampbell]

Bill,

Following your link to this, I reviewed what I had done and re-ran the tests.
I get the following elapsed times on a 1tb HDD

[wahorger]

Thanks, John, for the re-run and modification of the sharing.

The SHARE is important to my code, as multiple users can be accessing the same file; they are just not allowed to access it at the same time. So the SHARE being used is a logical consequence of this. Referring back to my previous message on this thread, the older system(s) did not have this issue with a performance penalty.

So, the question is whether or not the SHARE option is the culprit, or is it the OS? Or, is it a combination of both?

Thanks for running this benchmark comparison and continuing the thread toward, hopefully, a resolution.

[wahorger]

Perhaps someone can say if the SHARE option uses _fsopen() to accomplish this function, while if SHARE is not present, perhaps fopen()?

[JohnCampbell]

Bill,

I am interested to know why you need multiple write access to a direct access file. I suspect any multi-user database system would require this. This is not a typical use of direct access files, which does come with a performance penalty.

As to why sequential access is faster, isn't this because you can't have multiple write access for a sequential file, ie multiple write is not available for that type of file, or only a single user could append to the end of the file.

I think the reason why multiple write is slower on more recent versions of windows is because the file buffers are larger, so continually flushing the buffers after every write involves more disk I/O. Allowing multiple write would be equivalent to closing the file after every write operation.

John

[wahorger]

John,

Actually, I never allow multiple WRITE access, but I do allow multiple READ access (SHARE='DENYWR'). When I need exclusive access, I deny read and write (SHARE='DENYRW'). I had to play around with these a lot during the transition to FTN95.

The first attempt to limit other users from accessing the file was SHARE='COMPAT'. What in the old system was not more than the blink of an eye became a significant pause in the operation of the code, thus prompting the investigation 18 months ago.

I find it interesting that SHARE='DENYNONE' has the performance penalty. It would logically seem to be the same as SHARE=' '. Perhaps not...

In any event [and for me specifically], taking 99+% of the temporary/working files out and doing the job in memory means I don't have to worry this any more, but that's just me and it isn't a significant limitation to the program anyway.

Whether this is a "problem" or "just how it is", it is important for current and future users to be aware.

[JohnCampbell]

Bill,

Based on my testing example above, my interpretation of COMPAT is it should be the same as DENYRW, which is the same as SHARE=' '.
The only cases that allow multiple write are DENYNONE and DENYRD.

Either COMPAT is wrong, as it appears to be allowing multiple write or my interpretation is wrong ? If I understand this correctly, then COMPAT needs to be fixed.

Do you or anyone else know what is the correct interpretation of this problem ?

John