forums.silverfrost.com

DanRRight · Posted: Tue Jul 18, 2023 11:50 am Post subject:

Well, I have the same crashing behavior on Windows and Linux. These are two absolutely independed installations which do not know about each other. Plato was not used. Can anyone else try to run my read/write test?

My Linux noticed inconsistency in latest MOD files update, they now use capital letters, but in Windows that does not matter

PaulLaidler · Posted: Tue Jul 18, 2023 12:53 pm Post subject:

Dan

Which version of FTN95 are you using and what is the date for clearwin64.dll and salflibc64.dll?

mecej4 · Joined: 31 Oct 2006 Posts: 1886

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Dan,

I have now run your program on page 4, "Posted: Wed Jul 12, 2023 11:44 am"

It runs to completion, as did Paul's example, but with significantly different performance rates. I do not get your "Access violation"
I think Paul is correct to ask if you have consistent .exe and .dll files in your path.

Thinking about an aspect of this problem, I also changed your "Method 1" to write larger chunks of arr4 using:

DanRRight · Posted: Tue Jul 18, 2023 8:46 pm Post subject:

John, Finally! That was the only what i was asking for: to check if my latest test with latest FTN95 works.

I ran latest FTN95 update, all dates on files are 06/28 and 06/29, the update was from 8.92, and my support contract was and still is current

And i ran my latest test posted a week ago (my date on this post is shown as Tue Jul 11, 2023 5:44 pm, in other places the date and hour may vary, but minutes have to be 44)

After confirmations that all works I found the error in my compilation settings, and now all works (edited and forgot to return back /64. May be it's time to switch to /64 as a default ? Other compilers switched there long ago ).

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Dan,

So the answer is the latest FTN95 does not crash with your latest example.

There are 2 problems with this test example which you should also consider.

1) CPU_TIME is not appropriate for estimating disk I/O performance. This can be clearly seen from your method 2 where the processor is waiting for the IO operations to complete. This is demonstrated by different cpu time vs wall clock time which I included in my modified example.

2) The order of disk tests is also an issue as repeating the test changes the disk and memory environment. For method 2 read, the last write operation uses the identical (large) buffer as the previous write, so the information is already in the IO buffer and apparently the Windows I/O recognises this and does not do any read. This GByte/sec is not a realistic read rate estimate.

Stream I/O satisfies the portability of FTN95 and Gfortran.

Perhaps the next horizon is endianess !!

DanRRight · Posted: Fri Jul 21, 2023 12:41 am Post subject:

Paul, Based on your timings i was scratching the head on what kind of computers do you run this test? I do not know if in the nature yet existed such a computer Smile

. Aliens may have one which run Test1 with such huge boost. This was because of caching ? But i have not seen such tremendous effect of caching on Test1, all tests ran well below 1GB/s. Was there some secret compiler keys used?

PaulLaidler · Posted: Fri Jul 21, 2023 6:51 am Post subject:

Dell Inspiron 27 7710 All-in-One

Processor 12th Gen Intel(R) Core(TM) i7-1255U 1.70 GHz
Installed RAM 16.0 GB (15.7 GB usable)
System type 64-bit operating system, x64-based processor
Pen and touch No pen or touch input is available for this display

Windows 11 Home

512 GB Solid State Drive (M.2 SSD) + 1 TB Serial ATA (SATA)
Intel Iris Xe Graphics

DanRRight · Posted: Fri Jul 21, 2023 8:35 am Post subject:

I have no explanation for your numbers vs my AMD 5950X processor, 128GB RAM and WD850X NVMe storage besides you have DDR5 vs my DDR4:

https://nanoreview.net/en/cpu-compare/intel-core-i7-1255u-vs-amd-ryzen-9-5950x

But I have never seen any even super-duper fast memory could give more than 10% difference.

Have you modified my test? I see some signs of editions

Do anybody here have 12-13th generations of Intel Core processors and see such speeds with Method 1 ? Or AMD 5950X/7950X with DDR5 and PCIe 5.0 ? Use my test from page 4 above, nothing else

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

DanRRight · Posted: Tue Jul 25, 2023 6:53 am Post subject:

Paul, Your test results raised few questions because they are very unusual for the Test1. What memory type your PC has? Is it DDR4 or DDR5? Is bus PCIe 4 or PCIe 5? What storage type NVMe or harddrive? Did you edit my test on Page 4? Can you repeat my test one more time also measuring time by hand watch(approximately is also OK) or can you use SYSTEM_CLOCK (not adding to the test but substituting mine ) as JohnC claims this is problem with the timer (this claims look doubtful for the results of Test1 because test lasts for a long time and due to that the different timers differences have to be small)?

PaulLaidler · Posted: Tue Jul 25, 2023 7:51 am Post subject:

My machine is "out of the box" as described above. I don't recall needing to change your code.

With my limited knowledge in this area I think that the main issue is that it has "512 GB Solid State Drive (M.2 SSD)" and 16 GB of RAM.

Also "12th Gen Intel(R) Core(TM) i7-1255U 1.70 GHz",

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Dan,

Just publish a test that uses system_clock, rather than cpu_time, as if the processor is idle for I/O interupts, you just get a wrong result. It is BS to persist with a cpu_time test.

A 12th gen motherboard may benefit from PCIe 4.0 NVMe connection.

DanRRight · Posted: Tue Jul 25, 2023 10:26 pm Post subject:

cpu_time - bad timer?

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney