forums.silverfrost.com

DanRRight · Posted: Tue Mar 16, 2010 4:19 pm Post subject:

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.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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

PaulLaidler · Posted: Thu Apr 22, 2010 8:43 am Post subject:

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

DanRRight · Posted: Fri Apr 23, 2010 3:52 am Post subject:

"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 ?

IanLambley · Joined: 17 Dec 2006 Posts: 506 Location: Sunderland

I did know that, but I have forgotten!
Ian (1k memory)

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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

Wilfried Linder · Posted: Fri Aug 05, 2011 12:46 pm Post subject:

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

PaulLaidler · Posted: Fri Aug 05, 2011 1:40 pm Post subject:

There are currently no plans to write a 64 bit compiler but the possibility is continuously under review.

Sebastian · Joined: 20 Feb 2008 Posts: 177

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.

PaulLaidler · Posted: Mon Aug 08, 2011 7:09 pm Post subject:

No comment!

Sebastian · Joined: 20 Feb 2008 Posts: 177

That's pretty sad. Both things.

LitusSaxonicum · Posted: Tue Dec 11, 2018 12:07 pm Post subject:

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:

PaulLaidler · Posted: Tue Dec 11, 2018 5:23 pm Post subject:

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.

LitusSaxonicum · Posted: Tue Dec 11, 2018 6:31 pm Post subject:

Paul,

Thanks for the offer, but nothing I do is contingent on the answer. I write stuff that works within 1Gb of RAM, and it's now hard to find a computer with that little.

However, there's an important point or two here, I believe. That is if a 32bit app should be able to access most, if not all, of 4Gb when running in a 64bit Windows OS, then that provides a 'halfway house' between the limits in a 32bit OS and making the app 64bit.

The second point, if there is one, is that there isn't an error message - the program just doesn't run. I think that there should be.

What would suit me best is that you could give it some thought during idle moments (if you have such things) and possibly announce the solution some time in the future, having found the solution with a minimum of effort and with an 'Eureka moment', but without treating it as any kind of high priority.

After all, this thread began with you more or less stating that there wasn't going to be a 64-bit FTN95, and now there is.

Best regards

Eddie

PaulLaidler · Posted: Tue Dec 11, 2018 6:54 pm Post subject:

Eddie

Unfortunately there are no easy answers as to how memory is allocated. Hopefully things will get simpler and better as the 64 bit compiler progresses but further development for 32 bits seems unlikely.

For 32 bits, /CHECK mode has its own memory management with limited size.
Otherwise (for 32 bits) memory can be static, allocated from the stack or allocated from the heap. On 32 bit machines total memory allocation was limited to 2GB with the possibility of extension to 3GB via a switch at startup together with one in SLINK. The limits of 32 bit FTN95 on 64 bit machines remains largely unexplored though John Campbell may have some insights into this.