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 Previous  1, 2, 3  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: 1879
Location: South Pole, Antarctica

PostPosted: Tue Mar 16, 2010 4:19 pm    Post subject: Reply with quote

EKruck,
Of course all may depend on the type of "sparsity" and the size of matrix. With block sparse matrix of the size of relatively "dense" blocks more then approximately 200x200 (the larger the better to minimize synchronization losses) you can easily get almost proportional scaling with number of CPUs on all compilers including FTN95 using parallel libraries from Equation dot com i use for a decade.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2007
Location: Sydney

PostPosted: Thu Apr 22, 2010 2:04 am    Post subject: Reply with quote

Paul,
Has anyone in Silverfrost/FTN95 done a review of what would be required to get a minimal 64 bit executable operation ? I am thinking of the combined functionality of having allocatable arrays > 2gb and access to clearwin+, ie as Win64 and not .net.
My expectation is that this minimal solution would need :-
- Slink_64 to create a 64 bit executable.
- ALLOCATE to be able to allocate arrays > 2gb.
- Arrays as subroutine arguments being able to span 2/4gb of memory so implied long addressing.
- Large allocatable arrays could also be local or in modules so these arrays need long addressing also.
- Managing array indexes as I*4 or I*8 could be left to the programmer, although the implied memory address would need to be I*8.
- I would expect that having a limit of the rest of the program in 2gb would certainly be acceptable for most, as my code is typically less than 5mb.
- Library routines may need to be able to accept memory addresses beyond 2gb, but as an initial startup some restriction on this could be included.
- Array intrinsics, such as DOT_PRODUCT would probably require large array support.

My review of other compilers is that they have not done much more. Is the Win64 instruction set much different from Win32 ?

This looks like a small subset of the compiler functionality, which a) shows how little I know of the compiler and b) shows how extensive the FTN95 functionality is, which would be lost as win64 becomes more utilised.

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Apr 22, 2010 8:43 am    Post subject: Reply with quote

John

Thank you for your input on this subject. The short answer is yes we have considered this. It is difficult to gauge how much time this would take but conservative estimates could easily start at a few man years.

I would like to think that there might be a short cut but at the moment none is apparent.

Paul
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Apr 23, 2010 3:52 am    Post subject: Reply with quote

"Simplest" shortcut solution is .... to do exactly as it was done in FTN77 in the era of transition from 16 bits to 32 bits and preserved in FTN95.

Means no restrictions besides 64-bitness. Means take as much as you can. If someone needs a million or even billion times more memory then current 2GB limit, then let him use it. If he does not have these million or billion GBs of physical memory - allow him the same genial trick of FTN77/95 as virtual common, very many real life tasks allow that kind of sparsity. With this solution this compiler will be again light years ahead of anything else on earth, but this time for many decades.

There always exist people, tasks and organizations which use 10^3, 10^4, 10^5 or even 10^6 times more memory. Real, physical memory. But there exist even more users who are ready to use seemingly infinite pool of 64bit virtual memory.

BTW, what is the size of memory of fly or ant ?


Last edited by DanRRight on Fri Apr 23, 2010 4:48 pm; edited 1 time in total
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 470
Location: Sunderland

PostPosted: Fri Apr 23, 2010 12:53 pm    Post subject: Reply with quote

I did know that, but I have forgotten!
Ian (1k memory)
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2007
Location: Sydney

PostPosted: Wed May 05, 2010 7:39 am    Post subject: Reply with quote

Paul,

Could a minimum FTN95_64 be :-
- support for SLINK_64 to generate a 64-bit exutable,
- Allocate > 2gb arrays and
- subroutine array arguments could be explicitly declared as huge ?

So :-
- Library routines limited to 2gb, so no change.
- Array intrinsics limited to 2gb, so no change.
- Write to/from big arrays could be excluded, so no change for I/O.

It would be good to generate a 64-bit exutable !

The code I would like to compile is
Code:
      SUBROUTINE REDCOL (A, B, NB, JB, JT, IL)
!
!   Reduces vector 'A' by block 'B'
!
      real*8,    dimension(*), huge, intent (inout)  :: a
      real*8,    dimension(*), huge, intent (in)     :: b
      integer*8, dimension(*), huge, intent (in)     :: nb
      INTEGER*4 JB, JT
      INTEGER*8 IL
!
      REAL*8    VECSUM_big
      EXTERNAL  VECSUM_big
!
      integer*8 I0, J, JBOT, JPOINT, JBAND, J0, JL
!
      IF (JB > JT) RETURN
      JBOT = NB(1)
      I0 = 1-IL
      DO J = JB,JT
         JPOINT = J - JBOT + 3
         J0 = NB(JPOINT) - J
         JL = NB(JPOINT-1) - J0 + 1
          IF (IL > JL) JL = IL
         JBAND = J - JL
          IF (JBAND < 1) CYCLE
         A(J+I0) = A(J+I0) - VECSUM_big (A(JL+I0), B(JL+J0), JBAND)
      END DO
!
      RETURN
      END

      REAL*8 FUNCTION VECSUM_big (A, B, N)
!
!   Performs a vector dot product  VECSUM =  [A] . [B]
!
      integer*8,                     intent (in)    :: n
      real*8,    dimension(n), huge, intent (in)    :: a
      real*8,    dimension(n), huge, intent (in)    :: b
!
      real*8    c
      integer*8 i
!
      c = 0.0
      do i = n,1,-1
         c = c + a(i)*b(i)
      end do
      vecsum_big = c
      RETURN
!
      END

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



Joined: 14 Nov 2007
Posts: 311
Location: DŁsseldorf, Germany

PostPosted: Fri Aug 05, 2011 12:46 pm    Post subject: Reply with quote

A question to the developers of FTN95:

Are there already plans for a 64-bits-version of FTN95 / ClearWin? Can you tell me when approximately it will be available?

Thank you and best regards
Wilfried
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Aug 05, 2011 1:40 pm    Post subject: Reply with quote

There are currently no plans to write a 64 bit compiler but the possibility is continuously under review.
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Mon Aug 08, 2011 3:00 pm    Post subject: Reply with quote

What happenings can move this from "review" to "action"? It has been noted several times by different people on this forum that there is a very urgent need for this.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Aug 08, 2011 7:09 pm    Post subject: Reply with quote

No comment!
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Tue Aug 09, 2011 7:12 am    Post subject: Reply with quote

That's pretty sad. Both things.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 961
Location: Aerospace Valley

PostPosted: Fri Nov 30, 2018 9:49 pm    Post subject: Reply with quote

I dropped on this post from 8 years ago by complete accident - original 64bit brainstorming session !!!!!, and thought I'd bump it up for historical reference as we now seem to be nearing 'the holy grail

Paul, back in April 2019ž0 yu wrote (bove):

Quote:
Thank you for your input on this subject. The short answer is yes we have considered this. It is difficult to gauge how much time this would take but conservative estimates could easily start at a few man years.


So . how many man-what's-it's has it taken (so far) ?

Was it as easy7difficult as you imagined back when you were a you were a 'young boy' back in 2010 (you'v surely developed a few grey hairs on the task Wink ) ?

How far still to go (I've picked up there's still quite a bit to shake-down concerning the 64 bit debugger) before we can refer to it as the full monty ?

Over to you much-wiser-than-me folks for debate ...
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 961
Location: Aerospace Valley

PostPosted: Fri Nov 30, 2018 9:49 pm    Post subject: Reply with quote

I dropped on this post from 8 years ago by complete accident - original 64bit brainstorming session !!!!!, and thought I'd bump it up for historical reference as we now seem to be nearing 'the holy grail

Paul, back in April 2019 you wrote (bove):

Quote:
Thank you for your input on this subject. The short answer is yes we have considered this. It is difficult to gauge how much time this would take but conservative estimates could easily start at a few man years.


So . how many man-what's-it's has it taken (so far) ?

Someone once also wrote:
Quote:
Perhaps someone someday will estimate how many man years has gone into producing the current FTN95 package and maybe give a comprehensive list of credits.


... which of course is a much bigger project to undertake, not least because some of those 'in-the-know' of the nužitty-gritty facts mau no longer be with us to explain and receive their accolades Sad

Was it as easy/difficult as you imagined back when you were a you were a 'young boy' back in 2010 (you'v surely developed a few grey hairs on the task Wink ) ?

How far still to go (I've picked up there's still quite a bit to shake-down concerning the 64 bit debugger) before we can refer to it as the full monty ?

Over to you much-wiser-than-me folks for debate ...
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Tue Dec 11, 2018 12:07 pm    Post subject: Reply with quote

I keep reading that 64 bit Windows allows 32 bit applications to use 4Gb. Now 32 bit Windows seems to limit applications to 2Gb, but with appropriate switches set, 3Gb is usable. That seems fair enough, as the 4Gb has to contain OS 'stuff'.

The 2Gb limit seems to apply for 32 bit FTN95 programs running under Windows 64, and that doesn't seem to me to be as reasonable. Suppose we take a program like this:

Code:

      PROGRAM BIG
      REAL*8 A(50000000),B(50000000),C(50000000)    !3*8*50=1200million
!      REAL*8 D(50000000),E(50000000),F(50000000)   !a
!      REAL*8 X(50000000),Y(50000000),Z(50000000)   !b
      INTEGER*4 J
      J=50000000
      A(J)=1.0D0
      B(J)=1.0D0
      C(J)=1.0D0
!      D(J)=1.0D0   !a
!      E(J)=1.0D0   !a
!      F(J)=1.0D0   !a
!      X(J)=1.0D0   !b
!      Y(J)=1.0D0   !b
!      Z(J)=1.0D0   !b
      WRITE(*,*) A(J), B(J), C(J)
!      WRITE(*,*) D(J), E(J), F(J)   !a
!      WRITE(*,*) X(J), Y(J), Z(J)   !b
      END


It runs fine, and produces the correct output of 3 ones.

Now, uncomment the lines marked !a, and although it seems to compile and run, it does not produce any output or error message. The same happens if both the !a and !b lines are uncommented. Clearly !a puts it over 2Gb, but !a and !b combined don't put it over 4Gb.

Can someone please clarify this for me? Doesn't the 'too big' problem deserve some sort of message?

Eddie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Dec 11, 2018 5:23 pm    Post subject: Reply with quote

Eddie

I could investigate this issue for you if it is critical to your development program.

No doubt the memory usage has some limiting factor but tracking the point of failure and whether or not there should/could be a failure message may be non-trivial and hence time consuming.
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  Next
Page 2 of 3

 
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