forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Bug in SCC 3.88
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Dec 23, 2016 12:50 pm    Post subject: Reply with quote

Mecej4, Oh, c'mon, that is different story. Binary vs text output question is closed in favor of binary in my case because the text IS UNACCEPTABLY SLOW. By 10x as we can see. Even binary 4GB/s is far from peak 12 GB/s i'd like to see. Lose 3 seconds per day and you will lose 24h day at the end of your life. With our TBs of data we lose hours per day, or many years per life.

Everyone else decide by themselves to keep output text or binary. If speed and size is not an issue text is of course preferable.

Now question to Silverfrost: can we get 12GB/s and be by the light years the leader of Fortran market like in numerous important aspects it always was before?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Fri Dec 23, 2016 1:51 pm    Post subject: Reply with quote

Quote:
Now question to Silverfrost:


A very short question after a long discussion that I have not followed.

I am aware of some inefficient code in the FTN95 library for 64 bit formatted PRINT/WRITE of REAL values. We aim to fix this in due course but it is not an immediate priority.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Dec 23, 2016 1:54 pm    Post subject: Re: Reply with quote

DanRRight wrote:
Binary vs text output question is closed in favor of binary in my case because the text IS UNACCEPTABLY SLOW.

is incompatible with
Quote:
Guessing why Salford made byte readf@ and character readfa@ but did not make real*4 and real*8 utilities? How best way to convert real*4 number into 4 character*1 numbers and vice versa?


READF@ is type-agnostic. A byte is mostly typeless. Byte variables, if a language allows them, are usually catch-all-type variables which let you hold data until you cast or convert to/from a desired type, such as REAL, INTEGER, etc. Thus, READF@ is already capable of reading data that happen to be IEEE bit representations of REAL. So, you do not need "real*4 and real*8" utilities.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Dec 23, 2016 2:08 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:

A very short question after a long discussion that I have not followed.

I am aware of some inefficient code in the FTN95 library for 64 bit formatted PRINT/WRITE of REAL values. We aim to fix this in due course but it is not an immediate priority.

Paul, in this thread I posted a test program (FIOASC) on 22 Dec. 2016 which simply writes a CHARACTER(len=64) to a file repeatedly (64 MiB total) using WRITEFA@. No format conversion is involved, it suffices to keep track of line feeds. The write phase of this program takes 10X longer with /64.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Fri Dec 23, 2016 2:43 pm    Post subject: Reply with quote

mecej4

Thank you. I have looked at WRITEFA@ and made changes that will hopefully fix the problem.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Dec 23, 2016 3:06 pm    Post subject: Reply with quote

Paul,

My request was to find out what keeps readf@ limit on 4 GB/s instead of 12 - is it parallelization or something else.
When you will test unformatted I/O which is fast and should be even faster please use larger data 300MB minimum as the timer is not as high resolution. To save your time here is BAT file for the last code with the stack adjustments for 32 bit version

Code:

ftn95 equiv.f95  /set_error_level error 298 /no_truncate /nocheck /silent /opt >equiv_FTN895
slink equiv.obj  /stack:1200000000   >equivLink
equiv.exe >zz


Make sure you are running the code on RAMdisk. Test RamDisk speed itself, it has to be in 10+ GB/s territory.

mecej4 wrote:

"...aaa is incompatible with bbb... Thus, READF@ is already capable of reading data that happen to be IEEE bit representations of REAL"

Who knew that for sure before the test clearly showed that ?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Dec 23, 2016 4:34 pm    Post subject: Re: Reply with quote

DanRRight wrote:
mecej4 wrote:
Thus, READF@ is already capable of reading data that happen to be IEEE bit representations of REAL

Who knew that for sure before the test clearly showed that ?

Anyone who has programmed in C or has used C programs. open(), close(), read() and write() are all standard system calls in Unix, and have been with us since the 1970s. The FTN95 nonstandard subroutines provide the Fortran programmer access to the same functionality. Perhaps, they were added when FTN77 or FTN95 was ported to Linux in the 1990s.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Fri Dec 23, 2016 4:41 pm    Post subject: Reply with quote

Dan

If you can simplify this issue into a small program with simple test data then I will log it for investigation.

With so many issues going on at one time it is not easy for us to get quickly into a given problem. Also its a long time since I used a RAMdisk. All of these things are time consuming and the simpler it is for us, the quicker we can respond.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Dec 23, 2016 7:08 pm    Post subject: Reply with quote

Paul,

The small codes you ask are all posted above (for binary output) and are the same and super simple if you already looked at what mecej4 asked for text output. You just have to find why readf@ having limit 4 GB/s and if it is possible to get 10-12GB/s. If speed is defined only by Microsoft I/O DLLs like Mecej4 claims then you simply must get those 10-12 GB/s with some code optimization because these top speeds should be compiler-independent.

Without RAMdisk (or they are also called RAMdrives ) all this will not work because the latency and bandwidth of even fastest SSD is not enough to squeeze the crazy numbers like 12GB/s.
So you will need to install some free RAMdrive.

And need install CrystalDiskMark or any other popular disk drive speed testers to see if your RAMdrive is fast enough. The RAMdrives are just generally very good, they are good for fast compilation and fast loading of large files

Benefit for all that if you reach 10GB/s speeds is that you will claim that the new 64bit compiler is "Big Data ready" with its tremendous unseen before I/O speed numbers. Mecej4 and John will make comparison with Intel, Lahey, gFortran and all people will just drop the jaws under the tables seeing the read and write bars going to sky versus say gFortran - two-three orders of magnitude higher !
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Fri Dec 23, 2016 7:32 pm    Post subject: Reply with quote

Dan

I can only repeat, if you will post the code, the data and details of the command line arguments then I am happy to log it as worthy of attention. It is a lot easier for you to post again than for me to work out which code etc that you are referring to. I have not read this thread in detail and it would take a significant amount of time to read and understand it.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Dec 23, 2016 7:44 pm    Post subject: Reply with quote

OK, here is the code with all the command lines and explanations. You have just look at the numbers of write and read speed in GB/s it generates. The read speed is what could be super-high, in my case it is 4.4GB/s but the peak read and write speeds CrystalDiskMark shows for my RAMdisk is 12GB/s

Code:
! compilation for 32bit case :
! ftn95 equiv.f95  /set_error_level error 298 /no_truncate /nocheck /silent /opt >equiv_FTN895
! slink equiv.obj  /stack:1200000000   >equivLink
!
integer, parameter :: ix = 10, iy=800000, iz=10 
integer, parameter :: BSIZ = 4 * ix * iy * iz 
character (Len=1)  :: buf(BSIZ), bufRead(BSIZ)
integer*2          :: hndl, ecode
integer*8          :: nbytes = BSIZ
integer              :: nread
!
!......... here is the major trick ...........
real*4 A(ix,iy,iz)      ! Initial Big Data
equivalence (A,Buf)     ! converts initial real*4 data to character*1
real*4 C(ix,iy,iz)      ! Final  Big Data
equivalence (C,bufRead) ! converts loaded  character*1 data real*4
!
!............. setting up data ...............
do iiz=1,iz
 do iiy=1,iy
  do iix=1,ix
   A(iix,iiy,iiz) = iix
  enddo
 enddo
enddo

print*, 'A=', A(1,1,1), A(2,1,1)

!............writing to disk..................

call openw@('Y.bin',hndl,ecode)
if(ecode /= 0)stop 'Error opening file Y.BIN for writing'
call cpu_time(t1)
call writef@(buf,hndl,nbytes,ecode)
call cpu_time(t2)
if(ecode /= 0)stop 'Error writing file Y.BIN'
call closef@(hndl,ecode)
write(*,'(A,2x,i7, F7.3,A)')'Time for writing file of size MB: ',BSIZ/1000000, t2-t1,' s'
write(*,'(A,6x,F6.0,A)')'Estimated throughput = ',BSIZ/1000000/max(1.e-6,(t2-t1)),' MB/s'

! ...........reading from disk................

call openr@('Y.bin',hndl,ecode)
if(ecode /= 0)stop 'Error opening file BIG.BIN for writing'
call cpu_time(t1)
call readf@(bufRead,hndl,nbytes,nread,ecode)
call cpu_time(t2)
if(ecode /= 0)stop 'Error reading file BIG.BIN'
call closef@(hndl,ecode)

write(*,'(A,2x,i7, F7.3,A)')'Time for reading file of size MB: ',BSIZ/1000000, t2-t1,' s'
write(*,'(A,6x,F6.0,A)')'Estimated throughput = ',BSIZ/1000000/max(1.e-6,(t2-t1)),' MB/s'

print*, 'Checking if C=A', C(1,1,1), C(2,1,1)

end


Last edited by DanRRight on Sun May 16, 2021 8:33 am; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Dec 27, 2016 3:19 pm    Post subject: Reply with quote

Hello fellow FTNners, hope you all having great holidays and do not drink and drive, while compiler developers -- do not drink and coding. My condolences to them, we use great Fortran compiler but they develop it by using C compiler which does not find probably a tiny fraction of the bugs the FTN95 finds, the C source code is less readable and its size is vastly larger becoming at some threshold hardly manageable Wink. What is the FTN95 source code size now, BTW?

We on our North Pole though are working as usual, supercomputers are blinking day and night, specifically well during the holidays because are much less busy... Here is interesting follow up of the last I/O speed topic. It looks like the non-portable openr@ and readf/writeF and binary data as a medium for fast transfer are actually not needed at all which is of course much more convenient.

Here is an example of the same code as above but with the usual OPEN and READ/WRITE statements showing exactly the same unformatted write/read speeds 2 and 4 GB/s respectively but of course with some devilry like it always was with this compiler.

If you remove the line i marked with stars which is doing absolutely nothing and has no purpose at all because the binary arrays Buf and BufRead are not used now

Code:
equivalence (C,bufRead)


the reading speed drops twice from 4 GB/s to 2GB/s. Any ideas why?

Note, that adding same equivalence of array A with binary array Buf does not change writing speed or anything else.

Code:

! compilation for 32bit case :
!
! ftn95 unfRead.f95 /opt /set_error_level error 298 /no_truncate /nocheck /silent >equiv_FTN95
! slink unfRead.obj /stack:1200000000
!
integer, parameter :: ix = 10, iy=800000, iz=10 
real*4 A(ix,iy,iz), C(ix,iy,iz)

integer, parameter :: BSIZ = 4 * ix * iy * iz 
integer*2          :: hndl, ecode
integer*8          :: nbytes = BSIZ, nread

! adding or removing this line changes nothing
! equivalence (A,Buf)     ! converts initial real*4 data to character*1
! **** Removing this useless line decreases reading speed 2x ****
 equivalence (C,bufRead) ! converts loaded  character*1 data real*4


!............. setting up data ...............
do iiz=1,iz
 do iiy=1,iy
  do iix=1,ix
   A(iix,iiy,iiz) = iix
  enddo
 enddo
enddo

print*, 'A=', A(1,1,1), A(2,1,1)

!............writing to disk..................

OPEN (UNIT=275,FILE='Y.bin',STATUS='unknown',FORM='UNFORMATTED',err=990)
call cpu_time(t1)
write(275) A
call cpu_time(t2)
close(275)

write(*,'(A,2x,i7, F7.3,A)')'Time for writing file of size MB: ',BSIZ/1000000, t2-t1,' s'
write(*,'(A,6x,F6.0,A)')'Estimated throughput = ',BSIZ/1000000/max(1.e-6,(t2-t1)),' MB/s'

! ...........reading from disk................

OPEN (UNIT=275,FILE='Y.bin',STATUS='old',FORM='UNFORMATTED',err=995)
call cpu_time(t1)
read(275) C
call cpu_time(t2)
close(275)
write(*,'(A,2x,i7, F7.3,A)')'Time for reading file of size MB: ',BSIZ/1000000, t2-t1,' s'
write(*,'(A,6x,F6.0,A)')'Estimated throughput = ',BSIZ/1000000/max(1.e-6,(t2-t1)),' MB/s'

print*, 'Checking if C=A', C(1,1,1), C(2,1,1)
goto 10000

!................. errors ......................
990 Print*, 'Error opening file Y.BIN for writing'
goto 10000
995 Print*, 'Error opening file Y.BIN for read'
goto 10000
 
10000 continue
end
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed May 12, 2021 3:32 am    Post subject: Reply with quote

With the new NVMe PCIe 4 "haddrives" the read/write speed reach 8 and 6 GB/second !

Amazing is also the size and weight of these drives: they are less than crossection of a finger and weight less than few grams (WD Black SN850)
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Thu May 13, 2021 1:54 am    Post subject: Reply with quote

Dan,

These transfer rates are indeed impressive.

It is difficult to actually create test programs for these drives that do not just test the I/O buffers, both in Windows O/S and also in the NVMe drives (which do have significant buffering)

The problem remains in how to utilise this performance in practical computing.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu May 13, 2021 7:31 pm    Post subject: Reply with quote

HDF5. We need FTN95 compatible drivers for HDF5.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
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