View previous topic :: View next topic |
Author |
Message |
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Sun Feb 14, 2010 12:28 pm Post subject: 64-Bit FTN95 Compiler |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Mon Feb 15, 2010 2:56 pm Post subject: |
|
|
There are no plans at the moment to produce a 64 bit compiler. |
|
Back to top |
|
|
Emanuele
Joined: 21 Oct 2009 Posts: 77 Location: Bologna (Italy)
|
Posted: Sun Feb 21, 2010 11:52 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Wed Feb 24, 2010 3:04 am Post subject: |
|
|
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... 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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Feb 24, 2010 5:15 am Post subject: |
|
|
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 |
|
|
JohnHorspool
Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK
|
Posted: Wed Feb 24, 2010 8:58 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Feb 24, 2010 12:00 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Thu Feb 25, 2010 12:30 am Post subject: Re: |
|
|
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 |
|
|
JohnHorspool
Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK
|
Posted: Thu Feb 25, 2010 9:03 am Post subject: |
|
|
So how has the gnu compiler gfortran implemented 64bit? (I couldn't get g95 to run under XP64) |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Thu Feb 25, 2010 9:56 am Post subject: |
|
|
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 |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Thu Feb 25, 2010 10:32 am Post subject: |
|
|
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 |
|
|
JohnHorspool
Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK
|
Posted: Thu Feb 25, 2010 8:48 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Thu Feb 25, 2010 11:33 pm Post subject: |
|
|
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 |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Fri Feb 26, 2010 9:53 am Post subject: |
|
|
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 |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Sat Mar 13, 2010 5:55 pm Post subject: |
|
|
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 |
|
|
|