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 

64-Bit FTN95 Compiler
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
EKruck



Joined: 09 Jan 2010
Posts: 77
Location: Aalen, Germany

PostPosted: Sun Feb 14, 2010 12:28 pm    Post subject: 64-Bit FTN95 Compiler Reply with quote

Is there any perspective for a Silverfrost Fortran Compiler generating 64-bit code to overcome the 32-bit limitations, and to enhance speed?
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Mon Feb 15, 2010 2:56 pm    Post subject: Reply with quote

There are no plans at the moment to produce a 64 bit compiler.
Back to top
View user's profile Send private message
Emanuele



Joined: 21 Oct 2009
Posts: 57
Location: Bologna (Italy)

PostPosted: Sun Feb 21, 2010 11:52 pm    Post subject: Reply with quote

That's a pity! I've grasped that it is a hard task, but I'm persuaded it's a vital point for the future of fortran.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 938
Location: San Francisco,USA

PostPosted: Wed Feb 24, 2010 3:04 am    Post subject: Reply with quote

That's really very pity... Who'd expect 64 bit would not be a piece of cake for this company? I asked this same question more then 10 years ago...but seems real life is like stock market: past performance does not guarantee future results... Sad Even despite soon every cell phone will have more RAM memory then 32bit compiler can address

Paul, or Dave Bailey, can you give us a hint why this could be so difficult for the company which came first into the 32-bit market and even made great trick with addressable space like Virtual Common no others were able to approach?

Last one gave for example us immediately in 80th and 90th, in the era of 1MB RAM computers the ability to address the whole 2GB address space. That will be even more important in the 64bit era, since now we will need around 1.5*32=48 years to exhaust this new limit instead of 1.5*16=24 like we have done with 32bits going from 16 bits (i assume the memory increases my Moore's law - twice, or one bit, every 1.5 years)

I wrote already couple of times here what real hell causes often this 32-bit restriction of 1.6GB in my code which waits for 64bits for a long time, basically from the end of 1980th.

Here is an example what you get when your resources are exhausted: Here is debugger screenshot where you can clearly see that all variables have non-zero value but the final result of even such simple expression as sqrt(99.) is ... zero! This place in the code was clearly sporadically corrupted. No any potential bug warnings was produced by compiler of course and all arrays are consistent.



I will try to fix this by changing stack size back and forth to fit the program into 1.6GB so this error will probably disappear here (or change compiler options, shuffle subroutine positions etc). But the error may appear in some other parts of this large code. Good is that not all parts of the code are used simultaneously, so things will be OK until i will be stopped doing something else.

That all stopped me from making this code more complex internally but simpler and with more natural options externally. Searching for unexplainable bugs several times per day in such crazy code which could stop working when it wants to would be permanent hell
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1242
Location: Sydney

PostPosted: Wed Feb 24, 2010 5:15 am    Post subject: Reply with quote

The implementation of 64-bit fortran by Intel and Portland does not appear to be very extensive. It is very like when the Microsoft fortran compiler went from 16-bit to 32-bit and imlemented the huge attribute for arrays.
With these 64-bit implementations, they appear to be 32-bit compilers, but allow that some arrays can span a 32-bit address space. You have to give an array as being huge, so the address of the array or arguments of a subroutine can cross 2gb memory limits.
The code space is limited to less than 2gb, which I don't see as a big limitation. I never go anywhere near that limit, with typically less than a few mb.
With both 64-bit compilers you can only access big arrays by using ALLOCATE. They do not allow large arrays to be pre-defined or in COMMON, so it sounds like the linker is very similar to a 32-bit linker. The program is basically a 32-bit program fully contained in 2gb, but with allocatable arrays being allowed to have addresses beyond the 2gb limits. Paul, this looks very similar to the /3gb test program you assisted me with previously.
I presume you would have an allocatable array defined in a module then address it via the module or through subroutine arguments, which requires arguments to a subroutine having huge status. Most array intrinsics would need to cope with huge arrays.

My point is: I don't think there has been a "lot" done by Intel and Portland to enable 64-bit addressing arrays. Could Salford review these other limited 64-bit compilers and see if you could provide a /huge status for subroutine arguments and allocatable arrays in a 64-bit addressing environment ? There would need to be changes to SLINK, but the assembler code must look fairly similar to the 32-bit already generated.

Maybe David Bailey could do it again! I would love to have access to Clearwin+ with a large memory data set.

John
Back to top
View user's profile Send private message
JohnHorspool



Joined: 26 Sep 2005
Posts: 270
Location: Gloucestershire UK

PostPosted: Wed Feb 24, 2010 8:58 am    Post subject: Reply with quote

John,

Do the programs compiled using the 64bit fortran of Intel and Portland appear in task manager with "*32" after their names?

I have compared silverfrost against 64bit gfortran on my machine with number crunching code. The gfortran compiled exe was listed as a 64bit program in task manager. However it was significantly slower than the 32bit silverfrost compilation!!
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1242
Location: Sydney

PostPosted: Wed Feb 24, 2010 12:00 pm    Post subject: Reply with quote

John,
I'm still waiting for my 64-bit desktop !!
I've done a lot of reading, but am yet to actually run a useful program that uses more than 2gb.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 938
Location: San Francisco,USA

PostPosted: Thu Feb 25, 2010 12:30 am    Post subject: Re: Reply with quote

JohnCampbell wrote:
...They do not allow large arrays to be pre-defined or in COMMON, so it sounds like the linker is very similar to a 32-bit linker...

Yes, John, exactly. I do not like what Intel have done, it would be much more advantageous to make everything like it was done by great FTN77 by allowing people to address the whole address space, this time 10^9 times of what we have now ! Programming this way will have the future. And we will be able do sparse matrix stuff, multidimensional optimizations, or similar sort of things of the end of 21 century TODAY
Back to top
View user's profile Send private message
JohnHorspool



Joined: 26 Sep 2005
Posts: 270
Location: Gloucestershire UK

PostPosted: Thu Feb 25, 2010 9:03 am    Post subject: Reply with quote

So how has the gnu compiler gfortran implemented 64bit? (I couldn't get g95 to run under XP64)
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1137
Location: Yateley, Hants, UK

PostPosted: Thu Feb 25, 2010 9:56 am    Post subject: Reply with quote

So how do FTN95 32-bit programs run on a 64-bit version of Windows? Do they each run in their own (up to) 4Gb space, or do they all have to run in a single virtual 32-bit Windows space?

Eddie
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 169

PostPosted: Thu Feb 25, 2010 10:32 am    Post subject: Reply with quote

Quote:
So how do FTN95 32-bit programs run on a 64-bit version of Windows? Do they each run in their own (up to) 4Gb space, or do they all have to run in a single virtual 32-bit Windows space?

All 32bit applications (not only ftn95-compiled programs) run in a 32bit virtual address space (2GB usually) on 64bit windows.


Quote:
I have compared silverfrost against 64bit gfortran on my machine with number crunching code. The gfortran compiled exe was listed as a 64bit program in task manager. However it was significantly slower than the 32bit silverfrost compilation!!

What gfortran version did you use? On what OS/hardware? What compilation flags did you use for gfortran?
Back to top
View user's profile Send private message
JohnHorspool



Joined: 26 Sep 2005
Posts: 270
Location: Gloucestershire UK

PostPosted: Thu Feb 25, 2010 8:48 pm    Post subject: Reply with quote

Sebastien,

I have windows professional X64 edition version 2003 SP2 running on AMD Phenom 9600 Quad-Core with 8 gigabytes of ram

I got 64bit gfortran from here:-

http://gcc.gnu.org/ml/fortran/2007-09/msg00359.html

to run the same test calculation here are cpu times on my machine :-

gfortran 64bit cpu = 5.8 seconds
gfortran 32bit cpu = 5.4 seconds
silverfrost cpu = 4.4 seconds

I didn't set any compilation flags, just compiled with:-

C:\gfortran-win64\win64\bin\x86_64-pc-mingw32-gfortran.exe -o fe.exe *.for

cheers,
John
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1242
Location: Sydney

PostPosted: Thu Feb 25, 2010 11:33 pm    Post subject: Reply with quote

John,

I would expect that you ran the same problem with the same solution approach to get these times.
My aim is to configure the 64-bit version to utilise more memory and reduce disk I/O, hopefully substantially, to get better performance times.
As I've probably said before, watching a 32-bit program transfer 1gb blocks of memory to disk gives me lots of time to consider a faster approach! I have a number of problems that would benefit from 8gb of available memory and probably run in about 10% of the time.
Once I have the 64-bit version running, I will then be chaseing how to parrallel with the quad-core processors.

John
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 169

PostPosted: Fri Feb 26, 2010 9:53 am    Post subject: Reply with quote

Quote:
I didn't set any compilation flags, just compiled with:-

The standard flags of gfortran disable all sorts of optimizations so you should really have a look at usable optimization settings (for example -O2) and architecture-specific flags (unless you REALLY want it to run on a 80386 as well).
Check for example http://www.polyhedron.com/pb05-win32-f90bench_p40html


Quote:
I have a number of problems that would benefit from 8gb of available memory and probably run in about 10% of the time.

I can only second that, moreover there are cases where a limit of less than 4gb results in unusable programs when dealing with large amount of data.
Back to top
View user's profile Send private message
EKruck



Joined: 09 Jan 2010
Posts: 77
Location: Aalen, Germany

PostPosted: Sat Mar 13, 2010 5:55 pm    Post subject: Reply with quote

John,
I askes for the 64-bit compiler because I would like to use as well more memory for my large sparse matrices to reduce disk I/O.
I made another trial to speed the computation up using Intel-64-bit Fortran, Intel-32-bit Fortran and Salford Fortran. Intel provides parallel processing techniques and I destributed my matrix computations to all 4 CPUs. Unfortunately the result was simply wrong. The Intel compiler "forgots" sometimes to add the results from one or two of the threads. I wrote my own thread management. The result was then correct.
When using one thread only I got the same computation times from all my trials with differnt compilers.
Using all 4 CPU, I saw 100% CPU usage in the task manager. However, the total computation time was about 25 to 30 % HIGHER ! My conclusion: parallel processing for sparse matrices under Windows is not efficient, because taks switching is too slow.
Therefore: We need more memory to become faster.

Erwin
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
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