|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Fri Nov 11, 2016 1:39 pm Post subject: |
|
|
Dan,
I have done some testing of both binary I/O and text I/O.
I have tested on 2 desktop pc's
i5-2300 with 8gb memory and HDD drives
i7-4790K with 32 gb memory and HDD and SSD drives
A preliminary description of the test results in in the linked word document:
https://www.dropbox.com/s/sif5ect54kqh0zn/test_results.docx?dl=0
The text I/O test program is fairly simple, (I wrote it in an hour so hopefully works correctly!!) It creates files of 130 gb, so needs a bit of disk space. see link:
https://www.dropbox.com/s/ck1etkaqxzsx2wt/test_text.f90?dl=0
These results are very fast, much faster than you appear to be complaining about.
The results have been assembled via a spreadsheet and generated with a pivot table. I shall update these links as I check the results in the next few days.
John |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Fri Nov 11, 2016 2:06 pm Post subject: |
|
|
For those of us who nowadays only program in Fortran, Anton Kruger's 'Efficient Fortran Programming' (Wiley, 1990) contains Fortran routines for compressing and decompressing files using Huffman encoding. Chapter 10, pp 137-173.
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Nov 12, 2016 12:37 am Post subject: |
|
|
John,
Can you please post them here in usual text spreadsheet? We have policy not to open from the net any WORD, EXCEL, PDF script containing files, run EXE etc |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Nov 12, 2016 4:09 am Post subject: |
|
|
Dan,
The word document is 8 pages with 4 pages of text and 4 pages of charts, but unfortunately no pages of tables as yet. (only a draft)
Perhaps I could link to a text file of text and tables, although the charts are fairly useful.
Alternatively you could do the text file tests by downloading test_text.f90 and run it, as it does not need any libraries, only 130gb of disk space !
ftn95 test_text.f90 /debug /link /map ( or /opt )
Import file text_io.log into excel and this has elapsed time and mb/sec stats for all file operations.
I should have stated the i5 has Win 7_64 and i7 Win 10
I'd be interested in your test results.
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Nov 12, 2016 11:31 am Post subject: |
|
|
John,
OK, from my lately very damn busy fox hole in North Pole (you probably know my saying "Who is not working Saturdays does not work at all" (c) ) there is something strange there. Reading Numbers takes same time no matter what size. Reading text is around 250-350KB/s from SSD Samsung 850Pro, harddrive WD Black and RAMdrive, numbers - around 30
Also, is this real or an artifact that reading numbers is 10x slower then text (?)
Please check
/* If text is indeed 10x faster then 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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1894
|
Posted: Sat Nov 12, 2016 12:37 pm Post subject: Re: |
|
|
DanRRight wrote: | 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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Nov 12, 2016 1:13 pm Post subject: |
|
|
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: Code: | 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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Nov 12, 2016 1:35 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sun Nov 13, 2016 2:04 am Post subject: |
|
|
Dan,
Quote: | 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).
Code: | 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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sun Nov 13, 2016 6:21 am Post subject: |
|
|
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?
Code: |
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 |
Last edited by DanRRight on Sun Nov 13, 2016 9:02 am; edited 1 time in total |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sun Nov 13, 2016 8:50 am Post subject: |
|
|
Code: |
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 |
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sun Nov 13, 2016 12:21 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1894
|
Posted: Sun Nov 13, 2016 2:45 pm Post subject: Re: |
|
|
DanRRight wrote: | ... 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.
Code: | 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.
Quote: | 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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sun Nov 13, 2016 11:11 pm Post subject: |
|
|
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
Last edited by DanRRight on Mon Nov 14, 2016 12:54 am; edited 7 times in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sun Nov 13, 2016 11:40 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|