Silverfrost Forums

Welcome to our forums

Database or NetCDF / HDF5 interfaces?

12 Nov 2016 11:37 #18358

Quoted from DanRRight Also, is this real or an artifact that reading numbers is 10x slower than text (?) If text is indeed 10x faster than direct reading whole line of numbers then may be the faster solution will be to read first line of numbers at ones as single long text variable and then use another so called internal read to read these numbers from text variable

Formatted I/O of numbers is going to be significantly slower than unformatted/stream I/O because it takes time to convert from/to decimal floating point to/from internal binary IEEE format.

Instead of focusing narrowly on formatted I/O alone, you could think about (i) avoiding unnecessary/repetitious I/O, (ii) what your program does with the numbers that are read and written, and tailor the I/O operations to suit.

12 Nov 2016 12:13 #18359

Dan,

For the read text and read number text files, I tried to create tests where the file was not in memory buffers. The performance I recorded is in Mbytes per second as: Hardware read read text numbers (A80) (10F8.0) i5-HDD 67 53 i7-HDD 155 93 i7-SSD 172 93

As expected, the reading numbers is slower than read text, as there is more processing. With the i7, both disk types have similar performance @ 93 mb/sec. This was not expected! I assume from this that the performance is dominated by the time for converting of text to numbers, while disk I/O time is less significant. (I need to check this result and I should confirm if the conversion times are this slow)

For reading text only, this is faster, but I am surprised by the i7-HDD performance, as I would have expected similar to i5-HDD. Also I would have expected the i7-SSD to be much faster than i7-HDD than was reported. It is as if there is some memory buffering of the reading, but I can't see it from the test approach.

Still, 50 to 67 mb/sec on i5 and 100 to 170 mb/sec on i7 is fairly fast. You need to identify both disk I/O times and number format conversion times.

If you look at the results for binary reads, with the benefit of memory cache, the performance is much faster, at about 1 gb/sec, although reading a new file would not get this rate.

The main conclusion from this test is the estimated performance is much faster than your post of last week implied. Having available memory for cacheing is very effective.

John

12 Nov 2016 12:35 #18360

First, there probably is some error somewhere as I have around 300/30 MB/s for text/numbers no matter what PC and disks

In my task I am reading 9 numbers per line and get 31 MB/s (this is easy also to see in Task Manager/Processes/Disk Speed)

Given the copy speed in RAMdrive is 5000-7000 MB/s this gives 200x slower as I wrote above

Will try to modify to internal read in few minutes and see what this gives...

CONTINUE: Nope, no difference. Conversion takes too much time

EVEN MORE TRIES: If I use /nockeck /opt the speed gets to 56 MB/s. But if I use fixed format 9e13.7 instead of * the speed increases a bit to 75 MB/s

Better. Still not 7500 or 750 or at least 300 MB/s 😦 Do I have too unreasonable demands?

Also I remember Salford had its own reading commands READF@ and READFA@ instead of READ. Are they faster ?

How about other compilers?

13 Nov 2016 1:04 #18361

Dan,

Given the copy speed in RAMdrive is 5000-7000 MB/s

Your claims of ramdisk etc are not practical/achievable. These rates are faster than memory transfers and would only be available for targeted transfer instructions, with no processing of the contents.

I modified the test_text program to only do the number processing only, ie no disk transfers).

      do i = 1,2
        read (11,'(A)',iostat=iostat) line
      end do
!
      do i = 1,n
        read (line,fmt='(11f8.0)',iostat=iostat) aa
        if ( iostat /= 0) exit
      end do 

https://www.dropbox.com/s/std62006mih51c3/test_read.f90?dl=0

For processing numbers with a format (10F8.0) using FTN95 /link : Ver 8.05 I get: i5-2300 80 mb/sec, which is 12.8 seconds per gigabyte i7-4790k 141 mb/sec, which is 7.25 seconds per gigabyte

I previously reported for the i5 that read and process numbers is 53 mb/sec or 19.3 sec per gb, which means there is a delay of 6.5 seconds per gb for reading (read time is 6.5 sec plus due to buffering of the read)

For the i7, read and process is 93 mb/sec or 11.0 sec per gb, which means there is a delay of 3.75 seconds per gb for reading (read time is 3.75 sec plus due to buffering of the read)

Given the performance I reported in the previous post, these numbers look sensible. The read text times for the I7-HDD are much faster that the I5-HDD : 155 mb/sec vs 67 mb/sec, which may be due to a faster drive and faster processor. I was also surprised by the SSD rate of 172 mb/sec (I expected higher) but this limit is probably due to the limit of processing the read statement. character aa*80 read (11,'(a)',iostat=iostat) aa

The performance I have reported for binary transfers are much faster than these text transfers, as they benefit from no/minimal processing of the I/O list and also disk cacheing.

It looks that extra memory (for cacheing) may be a more flexible substitute for a SSD drive, although a SSD drive does separate the memory use and disk caching of available memory from SSD transfers for files and paging.

John

13 Nov 2016 5:21 (Edited: 13 Nov 2016 8:02) #18362

John Look at read and write test results of RAM drives, they all are in 5+ GB/s range. Definitely not with Fortran code. I'm pretty sure also all these tests were done with not overclocked processors and with typical ddr3 1600MHz modules or even DDR2 but they can go to 3200 MHz in extreme cases so transfer rates of RAM are larger, some also use RAID-like streams splitting.

Try RAMdrive, many are free. Or PCI Express based SSDs but they are typically more expensive. You also use few other compilers...

I do not understand what is few seconds buffering in your case and how you count it. Is this what you get?

 Opening File_1gb.txt : iostat=           0    1.000000E-04
            1 write_text     332.954     mb/sec     3.07550        13421774
 Opening File_2gb.txt : iostat=           0    3.000000E-04
            2 write_text     119.923     mb/sec     17.0776        26843547
 Opening File_4gb.txt : iostat=           0    8.000000E-04
            4 write_text     87.8678     mb/sec     46.6155        53687093
 Opening File_6gb.txt : iostat=           0    2.000000E-04
            6 write_text     115.922     mb/sec     53.0010        80530641
 Opening File_8gb.txt : iostat=           0    6.000000E-04
            8 write_text     94.4901     mb/sec     86.6969       107374185
 Opening File_10gb.txt : iostat=           0    2.200000E-03
           10 write_text     100.273     mb/sec     102.122       134217729
 Opening File_14gb.txt : iostat=           0    2.000000E-04
           14 write_text     94.2578     mb/sec     152.094       187904817
 Opening File_18gb.txt : iostat=           0    1.000000E-04
           18 write_text     93.4449     mb/sec     197.250       241591905
 Opening Number_1gb.txt : iostat=           0    2.000000E-04
            1 write_numb     30.7510     mb/sec     33.2997        13421774
 Opening Number_2gb.txt : iostat=           0    4.000000E-04
            2 write_numb     37.1232     mb/sec     55.1676        26843547
 Opening Number_4gb.txt : iostat=           0    2.000000E-04
            4 write_numb     37.1622     mb/sec     110.220        53687093
 Opening Number_6gb.txt : iostat=           0    1.000000E-04
            6 write_numb     37.1684     mb/sec     165.302        80530641
 Opening Number_8gb.txt : iostat=           0    1.000000E-04
            8 write_numb     37.0267     mb/sec     221.245       107374185
 Opening Number_10gb.txt : iostat=           0    4.000000E-04
           10 write_numb     36.8365     mb/sec     277.985       134217729
 Opening Number_14gb.txt : iostat=           0    1.000000E-04
           14 write_numb     36.9128     mb/sec     388.375       187904817
 Opening Number_18gb.txt : iostat=           0    2.000000E-04
           18 write_numb     36.8586     mb/sec     500.073       241591905
 Opening File_1gb.txt : iostat=           0    0.634000
13 Nov 2016 7:50 #18363
 Opening Number_1gb.txt : iostat=           0    0.100300
            1 read_numb     92.4931     mb/sec     11.0711         1.00000        13421775
 Opening Number_2gb.txt : iostat=           0    4.420000E-02
            2 read_numb     92.5687     mb/sec     22.1241         2.00000        26843548
 Opening Number_4gb.txt : iostat=           0    3.040000E-02
            4 read_numb     92.4252     mb/sec     44.3169         4.00000        53687094
 Opening Number_6gb.txt : iostat=           0    4.260000E-02
            6 read_numb     92.7522     mb/sec     66.2410         6.00000        80530642
 Opening Number_8gb.txt : iostat=           0    3.510000E-02
            8 read_numb     92.9064     mb/sec     88.1748         8.00000       107374186
 Opening Number_10gb.txt : iostat=           0    2.750000E-02
           10 read_numb     93.3271     mb/sec     109.722         10.0000       134217730
 Opening Number_14gb.txt : iostat=           0    5.080000E-02
           14 read_numb     93.3013     mb/sec     153.653         14.0000       187904818
 Opening Number_18gb.txt : iostat=           0    1.000000E-04
           18 read_numb     92.9581     mb/sec     198.283         18.0000       241591906
 Opening Number_1gb.txt : iostat=           0    5.060000E-02
            1 process_numb     141.638     mb/sec     7.22970         1.00000        13421774           0
 Opening Number_2gb.txt : iostat=           0    1.000000E-04
            2 process_numb     141.286     mb/sec     14.4954         2.00000        26843547           0
 Opening Number_4gb.txt : iostat=           0    3.460000E-02
            4 process_numb     141.092     mb/sec     29.0307         4.00000        53687093           0
 Opening Number_6gb.txt : iostat=           0    1.000000E-04
            6 process_numb     141.251     mb/sec     43.4971         6.00000        80530641           0
 Opening Number_8gb.txt : iostat=           0    2.000000E-04
            8 process_numb     141.062     mb/sec     58.0736         8.00000       107374185           0
 Opening Number_10gb.txt : iostat=           0    2.480000E-02
           10 process_numb     140.938     mb/sec     72.6559         10.0000       134217729           0
 Opening Number_14gb.txt : iostat=           0    2.670000E-02
           14 process_numb     141.211     mb/sec     101.522         14.0000       187904817           0
 Opening Number_18gb.txt : iostat=           0    1.000000E-04
           18 process_numb     141.078     mb/sec     130.651         18.0000       241591905           0
13 Nov 2016 11:21 #18364

Hi Dan,

I get similar to what you have presented on my i7, but report slower performance on my i5.

Your results are averaging: Write text : 100 mb/sec (variable due to managing memory cacheing) write number : 37 mb/sec (uniform) read text : ??? read number : 92 mb/sec (uniform) process number : 141 mb/sec (uniform)

From your results: read numbers is 1024/92 = 11.1 seconds per gigabyte process numbers is 1024/141 = 7.3 seconds per gigabyte so 3.8 seconds delay for reading file.

These read tests are basically un-buffered, although the early write tests would be buffered, hence the greater variability.

I am not sure I fully understand the claims about ram drives, as ddr3 1600 mhz is a transfer rate of 1.6 ghz x packet size. The other issue I suspect is that SSD drives use a disk driver and so are limited by the bandwidth of the pseudo device driver. Not sure if this is still a problem.

I think your practical limit for reading numbers is the 141 mb/sec, which is the processing rate; not much faster that the 92 mb/sec your disk provides. Basically about 10 seconds per gigabyte is what to expect for reading numbers from a .csv file.

I should do this test using FTN /64 to see if there is any change. Also, I should test gFortran as it may have a problem with this; it's speed can be very poor for processing I/O lists.

Hope this provides some context to what is practical performance for large files.

John

13 Nov 2016 1:45 #18365

Quoted from DanRRight ... there probably is some error somewhere as I have around 300/30 MB/s for text/numbers no matter what PC and disks ... How about other compilers?

As I stated earlier, I think that you should separate device I/O time from format processing time.

Here is a very different example case. The input file contained 580930 text records, each containing 58 characters, with LF as EOL. The C program is multithreaded, (i) reads the data file with a single block read() call, (ii) scans the block for LF to set up a pointer array to the individual records, (iii) sorts the records on a field, and (iv) outputs the sorted records to a file. All the files are on a Ramdisk (DataRam, not the fastest among the choices available) on a Dell laptop with i7-2720 CPU, 8 GB RAM.

PHASE                    TIME

Block read file          0.078 s
Split into records       0.015
Sort                     0.063
Output file              0.297

The block read time corresponds to a throughput of 440 MB/s, which is in the same range as what you have for 'text read'.

The file output was done with one call to fputs() for each record, plus an fputc('\n') for each record, and could be made faster by writing the sorted records to a buffer and doing block writes on full buffer.

I remember Salford had its own reading commands READF@ and READFA@ instead of READ. Are they faster ?

READF does a block read of raw data. You would have to separate the data into lines and read individual lines under format control. READFA reads one line at a time, so it should give similar performance to your 'text read' version.

13 Nov 2016 10:11 (Edited: 13 Nov 2016 11:54) #18366

The results I posted are done on harddrive. I can not use ramdrives temporally as I will need reboot for that while I'm under stressful deadline now. SSDs and all other drives are also full. As for transfer rates of DDR3 RAM - see for example Wiki. And currently more and more becoming mainstream DDR4 PC4-2400+ have 20 GB/s rates

On my own code I do not see improvement if I use text read into char variable first and then convert it into numbers with internal read

Please continue testing with other compilers and please check if READFA is heavily optimized for read as I remember this claim of Salford in the past.

Mecej4, though this could be of minor influence but still would be good if you adopt the same initial conditions for example take all sizes for ASCII read and numbers per line like in John's case. Also please do John's test for us to know how fast is your laptop on the same task at least for small file sizes

13 Nov 2016 10:40 #18367

Hi Dan,

I have been doing some other testing with FTN95 /64 and gFortran. They are both much worse for writing numbers to file, but better for reading numbers, which is your original question.

Paul, you should check FTN95 test_read.f90 /64 /link, as for the write number test using FTN95 /64, as I am getting 8.6 mb/sec vs 24.1 mb/sec for /32 on my i5-HDD pc. (you may want to only test smaller files, given the performance!)

Strangely FTN95 /64 is faster for processing numbers (133 mb/sec vs 80 mb/sec), reading numbers (89 mb/sec vs 56 mb/sec) or writing text (105 mb/sec vs 80 mb/sec). Not sure why an internal read is faster with /64 and also write text (??), but write numbers is so much slower. Hopefully FTN95 /64 /opt might have some answers.

gFortran is also much worse again for write numbers at 4.3 mb/sec for writing numbers, which is a known long term weakness for gFortran.

John

13 Nov 2016 11:06 (Edited: 14 Nov 2016 1:28) #18368

Well, good to know that 64bit compiler is faster on reading numbers, but...i can not use 64 bit compiler with currently not working well pre-beta debugger, this will kill me

Also, John, can you please reduce tests to 1,2,4,8,16 and make the log file less verbose and better visible so that we can post it here without much cutting (this forum is keeping to be way too restricting in post size despite over forum existence time the size and speed of harddrives increased probably by 10-100x and price per bit dropped by 1000x). And also automatically delete all files after their use

Here is SSD Samsung 850 Pro test with I7 CPU

 Opening File_1gb.txt : iostat=           0    1.000000E-04
            1 write_text     292.722     mb/sec     3.49820        13421774
 Opening File_2gb.txt : iostat=           0    1.000000E-04
            2 write_text     307.517     mb/sec     6.65980        26843547
 Opening File_4gb.txt : iostat=           0    2.000000E-04
            4 write_text     329.173     mb/sec     12.4433        53687093
 Opening File_6gb.txt : iostat=           0    1.000000E-04
            6 write_text     322.171     mb/sec     19.0706        80530641
 Opening File_8gb.txt : iostat=           0    6.000000E-04
            8 write_text     322.576     mb/sec     25.3956       107374185
 Opening File_10gb.txt : iostat=           0    1.000000E-04
           10 write_text     338.099     mb/sec     30.2870       134217729
 Opening File_14gb.txt : iostat=           0    4.000000E-04
           14 write_text     336.274     mb/sec     42.6319       187904817
 Opening File_18gb.txt : iostat=           0    1.000000E-04
           18 write_text     336.538     mb/sec     54.7694       241591905
 Opening Number_1gb.txt : iostat=           0    2.000000E-04
            1 write_numb     38.1252     mb/sec     26.8589        13421774
 Opening Number_2gb.txt : iostat=           0    2.000000E-04
            2 write_numb     38.1325     mb/sec     53.7075        26843547
 Opening Number_4gb.txt : iostat=           0    1.000000E-04
            4 write_numb     38.1490     mb/sec     107.368        53687093
 Opening Number_6gb.txt : iostat=           0    1.000000E-04
            6 write_numb     38.1250     mb/sec     161.154        80530641
 Opening Number_8gb.txt : iostat=           0    1.000000E-04
            8 write_numb     38.1276     mb/sec     214.857       107374185
 Opening Number_10gb.txt : iostat=           0    1.000000E-04
           10 write_numb     38.1685     mb/sec     268.284       134217729
 Opening Number_14gb.txt : iostat=           0    2.000000E-04
           14 write_numb     38.1640     mb/sec     375.642       187904817
 Opening Number_18gb.txt : iostat=           0    6.000000E-04
           18 write_numb     38.1899     mb/sec     482.641       241591905
14 Nov 2016 1:16 #18376
 Opening File_1gb.txt : iostat=           0    2.900000E-03
            1 read_text     179.908     mb/sec     5.69180         1.00000        13421775
 Opening File_2gb.txt : iostat=           0    3.100000E-03
            2 read_text     185.824     mb/sec     11.0212         2.00000        26843548
 Opening File_4gb.txt : iostat=           0    3.100000E-03
            4 read_text     189.945     mb/sec     21.5641         4.00000        53687094
 Opening File_6gb.txt : iostat=           0    3.200000E-03
            6 read_text     192.135     mb/sec     31.9776         6.00000        80530642
 Opening File_8gb.txt : iostat=           0    3.100000E-03
            8 read_text     192.985     mb/sec     42.4490         8.00000       107374186
 Opening File_10gb.txt : iostat=           0    3.600000E-03
           10 read_text     192.612     mb/sec     53.1640         10.0000       134217730
 Opening File_14gb.txt : iostat=           0    3.400000E-03
           14 read_text     193.060     mb/sec     74.2567         14.0000       187904818
 Opening File_18gb.txt : iostat=           0    3.300000E-03
           18 read_text     192.805     mb/sec     95.5994         18.0000       241591906
 Opening Number_1gb.txt : iostat=           0    3.600000E-03
            1 read_numb     97.9811     mb/sec     10.4510         1.00000        13421775
 Opening Number_2gb.txt : iostat=           0    2.700000E-03
            2 read_numb     98.0087     mb/sec     20.8961         2.00000        26843548
 Opening Number_4gb.txt : iostat=           0    2.900000E-03
            4 read_numb     97.9989     mb/sec     41.7964         4.00000        53687094
 Opening Number_6gb.txt : iostat=           0    3.100000E-03
            6 read_numb     98.0025     mb/sec     62.6923         6.00000        80530642
 Opening Number_8gb.txt : iostat=           0    3.000000E-03
            8 read_numb     97.9513     mb/sec     83.6334         8.00000       107374186
 Opening Number_10gb.txt : iostat=           0    3.200000E-03
           10 read_numb     97.8757     mb/sec     104.622         10.0000       134217730
 Opening Number_14gb.txt : iostat=           0    1.000000E-04
           14 read_numb     97.6361     mb/sec     146.831         14.0000       187904818
 Opening Number_18gb.txt : iostat=           0    1.000000E-04
           18 read_numb     97.4608     mb/sec     189.122         18.0000       241591906
 Opening Number_1gb.txt : iostat=           0    4.900000E-03
            1 process_numb     143.411     mb/sec     7.14030         1.00000        13421774           0
 Opening Number_2gb.txt : iostat=           0    4.400000E-03
            2 process_numb     143.457     mb/sec     14.2761         2.00000        26843547           0
 Opening Number_4gb.txt : iostat=           0    4.600000E-03
            4 process_numb     143.546     mb/sec     28.5344         4.00000        53687093           0
 Opening Number_6gb.txt : iostat=           0    4.400000E-03
            6 process_numb     143.029     mb/sec     42.9562         6.00000        80530641           0
 Opening Number_8gb.txt : iostat=           0    4.800000E-03
            8 process_numb     143.353     mb/sec     57.1455         8.00000       107374185           0
 Opening Number_10gb.txt : iostat=           0    4.800000E-03
           10 process_numb     142.998     mb/sec     71.6094         10.0000       134217729           0
 Opening Number_14gb.txt : iostat=           0    1.000000E-04
           14 process_numb     143.269     mb/sec     100.063         14.0000       187904817           0
 Opening Number_18gb.txt : iostat=           0    1.000000E-04
           18 process_numb     143.530     mb/sec     128.419         18.0000       241591905           0
14 Nov 2016 10:57 #18385

Dan,

Looks similar to what I am getting. Try ftn95 /64

John

15 Nov 2016 2:07 #18386

I tried 64 but scaled back to pure 32, some unknown and extremely rare problem made code to behave crazily (I call it devilry). Could also be not 64 (when I do not reboot computer for very long time) but I had no time to investigate, so I uninstalled and rebooted. I am waiting for 64bit debugger to be at least elementary functional.

Can you run the test on Intel or Lahey Fortran?

15 Nov 2016 10:02 (Edited: 15 Nov 2016 12:35) #18387

As you have already seen, formatted reads and writes of real numbers are expensive. Here are a pair of simple tests that involve almost no external I/O and make the point. No need to consider SSDs, Ramdisks, etc.

In the first example, I use a string variable containing one line similar to the lines generated in John's tests. I then read the ten real numbers using 10F10.3 as the format. I repeat this READ 1 million times, and write to the console after 100000, 200000, etc., 1000000 iterations. This WRITE is necessary to prevent the optimization phase of the compiler from making the whole loop vanish.

program FmtRead
implicit none
character(len=100) :: str
integer :: i,j
real, dimension(10) :: x
write(str,'(10F10.3)')(3.0*i-7.679,i=1,10)
do j=1,1000000
   read(str,'(10F10.3)')x
   if(mod(j,100000).eq.0)write(*,*)j,x(3)
end do
end program

This program, compiled with gFortran -O2, runs in 3 seconds on a cloud Linux server.

The second program is a modified version of the first, in which the internal READ is replaced by code that directly interprets the string in Fortran code, without going through the Fortran I/O runtime. It does not check for invalid characters, missing decimal points and other similar errors -- the input string is assumed to be valid for the format in question.

program IntlRead
implicit none
character(len=100) :: str
integer :: i,j,k,n,sgn,iv,fv,tp
real, dimension(10) :: x
write(str,'(10F10.3)')(-7.679+3*i,i=1,10)
do j=1,1000000
   do n=1,10
      k=(n-1)*10+1
      sgn=1
      do while(str(k:k) == ' ')
         k=k+1
      end do
      if(str(k:k) == '-')then
         sgn=-1
         k=k+1
      endif
      iv=0
      do while(str(k:k) /= '.')
         iv=iv*10+ichar(str(k:k))-ichar('0')
         k=k+1
      end do
      k=k+1; fv=0; tp=1
      do while(str(k:k) >= '0' .and. k <= n*10)
         fv=fv*10+ichar(str(k:k))-ichar('0')
         tp=tp*10
         k=k+1
      end do
      x(n)=sgn*(real(iv)+real(fv)/real(tp))
   end do
   if(mod(j,100000).eq.0)write(*,*)j,x(3)
end do
end program

On the same system, the modified code runs in 0.3 s. Thus, the convenience of formatted input can carry a hefty price tag. In a real program, therefore, it is worthwhile to minimize formatted I/O as much as possible. If the same file is read several times in the program, it may be advantageous to put the read data into memory during the first file reading and replace the subsequent file reads by memory copying.

15 Nov 2016 10:48 #18389

Yea, something like that for example. Or ultimately optimize something on assembler level.

I would expect Salford/Silverfrost to implement some kind of 'superfast read/write' utilities with some clearly defined restrictions to reach the peak speeds. It is pity to lose 99% of 20GB/s I/O bandwidth of modern hardware like PCI Express SSDs or DDR4 RAMdrives.

I'm still busy to check that myself (soon my colleagues will demand my body parts if I do not deliver in few more days what I promised), but may be you or somebody else have time to check unformatted read speed?

15 Nov 2016 11:14 #18390

mecej4,

I would like to draw attention to the poor performance of WRITE with /64 (and gFortran). I have a variant of your program that tests internal write, rather than read, as write with gFortran or FTN95 /64 is much slower than ftn95 (/32). Write is also slower than read. (Interesting read is faster with FTN95 /64 ?)

I have obtained the following performance using PLATO on my 2.6ghz i5-2300:

program fmtread ftn95 (Release Win32) : 1.083 seconds ftn95 /64 : 0.668 seconds gFortran : 6.157 seconds

program fmtwrite ftn95 (Release Win32) : 3.036 seconds ftn95 /64 : 9.28 seconds gFortran : 40.07 seconds ( I'm consistently getting 10x performance like this !!)

program FmtWrite
 implicit none 
 character(len=100) :: str 
 integer :: i,j
 real, dimension(10) :: x 
 real     del_sec, sec
 external del_sec
!
 sec = del_sec ()
 do i = 1,10
   x(i) = 3.0*i-7.679
 end do
 do j=1,1000000 
    x(3) = 3.0/j-7.679
    write (str,'(10F10.3)') x 
    if(mod(j,100000).eq.0)write(*,*)j,x(3) 
 end do 
 sec = del_sec ()
 write (*,*) sec,' seconds'
 end program 

   real*4 function del_sec ()
!
      integer*8 :: last_tick = 0
      integer*8 :: tick, rate
      real*4    :: dt
!
      call system_clock ( tick, rate )
      dt = real(tick-last_tick) / real(rate)      
      last_tick = tick
      del_sec   = dt
   end function del_sec

Lately, I have put in a lot of work to improve the performance of Finite Element linear equation solution in a 64-bit environment, only to find that the speed improvement obtained is lost when reporting the results to a text file.

15 Nov 2016 11:34 (Edited: 15 Nov 2016 2:07) #18391

John,

Can you add to your test read text + direct interpretation of the string like mecej4 showed? Numbers though have to have, say, 10 digits, in your example they are way too short

How is it faster then formatted read or text read + internal read?

15 Nov 2016 12:17 #18393

John, I think that the unacceptably slow formatted WRITE (and READ, but less serious in this case) performance of gFortran is attributable to the emulation layer (Cygwin, MinGW, etc.) used on Windows. Try running on a Linux system, or use a cloud service such as https://www.tutorialspoint.com/compile_fortran_online.php . (If you use this server, you have to replace 'integer8' by 'integer' and 'real4' by 'real'. Ignore the IDE they provide and compile in the command line pane to specify -O2 as the option. I get a run time of 5 s; as I reported above, the formatted read program on this server took 3 s.)

From past experience, I think that the GFortran people have very little interest in fixing problems on Windows. Personally, I have other Fortran compilers available to me on Windows, so I am not bothered much by GFortran problems on that platform.

There is some logical basis for expecting WRITE to be faster than READ. After the WRITE has been initiated, the program can continue to execute as long as the I/O unit concerned is not touched until later. READ, on the other hand, must complete before the next statements are executed because the compiler probably cannot know when the read data is going to be used.

On the other hand, most storage devices are slower at writes than reads.

16 Nov 2016 2:22 #18394

Mecej4, i just noticed that your simple code example for internal read works only for real*4 (not real8) F formatted numbers and also does not convert E formatted numbers. If you add what is missing will it be faster then standard formatted read like READ(11,'(10e10.3)') X ?

Also, anyone knows FTN95 library or WinAPI function to find the file size without opening it or deciphering DIR command prompt call?

Please login to reply.