- #Screen marker too slow software
- #Screen marker too slow code
- #Screen marker too slow Pc
- #Screen marker too slow windows
Every Fortran Runtime library has it's own sweet spots for record sizes vs performance. It is possible that MPS is faster for the case presented here.
However, the data is there in its current format, and this data has to be re-read and processed.Īnd for the native ifort written data - you removed the -fpscomp and -assume:buffered_io options? Does the buffered IO help in this case? I can of course remove the test from the loop and stare forlornly at my blank screen whilst my hard disk churns away, but the end result is the same - ifort-V11 is many times slower than MPS-V4.Īnd yes, if the data had been written differently it could no doubt be read back in a more efficient manner. The reason for the mod() and print() calls inside the loop are so that I can quickly see if any modifs I make to the source or compilation options have any effect on the execution time - with the Intel compiler I get a print every 2 seconds, with MPS it is 5 or 6 times that rate (two-to-three per second).
#Screen marker too slow Pc
And in reply to a previous question, yes, my timing test are all run on the same PC (XP-32bit).
#Screen marker too slow code
Why don't you yank that test/print code out of there, put a call to CPU_TIME() before and after the loop to get a clean timing on just the read time without also including all the if tests, the calls to MOD() and potentially the writes.Īs mentioned in reply to a previous suggestion I have re-created a "native" ifort copy of the original MPS data file, so my program is now running on a "native" file-format file.
#Screen marker too slow software
The extra software overhead would diminish to noise if the data was written as one record and you re-read that as one record, for example.Īlso, you have that whole mod() and print going on in the loop. You could amortize this cost with large block reads if the data was layed out differently in the file. And you're reading in small chunks, which means you're going through this extra layer of software translation for each read - and you have a boatload of reads going on. So you've added this compatibility layer of software that is slowing down the reads (and writes). You are using -fpscomp so that ifort can read this non-native file. The data file you are reading was created by another compiler and thus does not use the same storage format as that used by ifort.
There is no standard for these marks, so each compiler has it's own 'native' record and file marks. 'unformatted' data files have the data stored in binary format for sure, however there are record markers and file marks that need to delineate the data.
#Screen marker too slow windows
What is "odd" is that if I interrupt the program with Ctrl-Break, I get a Windows "Application Error" dialog displayed, but the program continues to run in the background, and the program print statements are now generated around 4 times more rapidly.ġ) Is this slow unformatted read performance a known issue?ģ) How come the program suddenly accelerates when I hit Ctrl-BreakĪfter thinking about this a bit more, I have a few other comments.įirst, you are reading a non-native file format in ifort. So my program prints to the console every 100000 reads.
Ifort -assume:byterecl -integer-size:32 -iface:cvf -warn:argument_checking -warn:truncated_source -fpscomp:ioformat -fp:source -MD -assume:buffered_io read_ud.f Open(10, open(10,file=c_FileName,form='unformatted',status='old') Reading this file back with Intel Fortran is around four times slower than reading the same file with Microsoft Power Station V4.00. I have a large (600MB) unformatted sequential file created by Microsoft Power Station V4.00.
0 kommentar(er)
