forums.silverfrost.com

LitusSaxonicum · Posted: Mon Mar 12, 2012 2:29 pm Post subject:

This forum is driven by software that allows polls to be conducted. Perhaps this facility could be enabled so that users could record their feelings about needs for future development?

Eddie

LitusSaxonicum · Posted: Mon Mar 12, 2012 2:35 pm Post subject:

Wilfried,

As far as your problem goes, then clearly it is NEVER solvable under a 32-bit OS, whether it is Windows or anything else. Having dabbled in photogrammetry and DTMs, then the answer must lie (if one must do it in a 32-bit OS) in doing it in panes or tiles � I presume that the two digital camera images have a stereoscopic overlap. This straightaway means that the only parts of the two camera images that really need to be in memory at any time are in the overlap. Not only that, but the image can be processed in bands or tiles thereafter. The movie industry renders images in tiles (see Autodesk Maya and its various add-ons).

Even assuming you need to have 2 photos and a DTM simultaneously in memory, this is still a small number of huge arrays, and my suggestion as to how to get limited 64-bit addressable arrays into FTN95 still applies: it might be do-able with as little as 4 arrays, i.e. the rest of FTN95 could stay 32-bit, as long as there was a way of creating those arrays, and interacting with the memory constants � and you could only do it in 64-bit Windows. Or, all ALLOCATABLE arrays could be 64-bit: static arrays still have to fit in 2Gb, and so by definition are not 64-bit addressable.

Eddie

Wilfried Linder · Posted: Mon Mar 12, 2012 3:01 pm Post subject:

Eddie,

within my stereo display both images (24 bits / real colours) are shown, connected with the DTM. The mouse movement changes x and y (terrain units), then the corresponding z value is taken from the DTM, then the image positions are calculated. In this way, a real-time movement is realised. You are right, tiling the images may be a solution - hope that real-time movement will still work.

And you are right that (for me) it would be enough if up to 4 arrays could be handled in "64-bit-mode". Nevertheless it would not only be necessary to allocate them but also to have functions like openr@, openw@, fpos@ and others available for such arrays. The 2GB limit for static arrays is no problem for me.

It would be nice if Silverfrost could realise this ...

Regards - Wilfried

DanRRight · Posted: Mon Mar 12, 2012 4:38 pm Post subject:

John, may be i'm lost something, i see how you've allocated around 3+smth GB but that's end of the game. How did you get 9?

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

Dan, I got 9gb using a 64-bit compiler.

Eddie, The result of using 64-bit is that you do not have to use tiling. This allows faster and simpler access to all the data, enabling new ways to present the information. When all the data is present, it is easy to try other ways to use the data, rather than the overhead of manageing the data sharing.

John

LitusSaxonicum · Posted: Mon Mar 12, 2012 10:04 pm Post subject:

Hi John,

Yes, I did understand that coding gets easier if everything is simultaneously in memory, and it probably runs (a lot) quicker too. But if you want to use 32-bit FTN95 with all the advantages of Clearwin, then you can run a tiled application, and you can't run an un-tiled one!

So what do you think of a poll of user wishes?

Eddie

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

Eddie,

I agree that a poll of user wishes would be a good idea to see what users of FTN95 would like to see available.

I would also like to get some feedback from Silverfrost as to what is possible and what resources and funding can be provided.
We see a lot of valuable support from Paul and others. I think a lot of this is provided by them in their "free" time.
If (say) the estimate for just getting to a 64-bit .exe is 1,000 hours, I'm sure there would be complaints if clearwin+, .net and all the library routines did not support memory addresses above 4gb. Depending on the funding model for Silverfrost, this amount of commitment could be a huge ask.

FTN95 is a very extensive system. Just look at all the enhancements for .net and Visual Clearwin, which I've never used!

I note that my copy of the Fortran 95 standard is 376 pages, while the draft of 2008 is 621 pages. There is a lot of new stuff in there to be implemented if FTN95 were to become FTN08.

Eddie, as you have asked; "if you want to use 32-bit FTN95 with all the advantages of Clearwin" then we need to be realistic.

John

EKruck · Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany

My only interests are to be able to use say 20 to 30 GB of RAM, and fast procssing destributed to all available processors. This reqires a 64-bit program.

My large optimisation programs are pure batch programs. They do not need Clearwin, or Visual Clearwin or .net.

All other programs using Clearwin may stay with 32 bits.

Erwin

LitusSaxonicum · Posted: Fri Mar 16, 2012 3:58 pm Post subject:

Hi Erwin,

Although I'm a huge fan of FTN95, it looks to me that this set of needs is better met with a different compiler. In the DBOS days, you would have used FTN77 because it was fast and allowed access to what was then the huge memory resource of Extended Memory. I do have 2 further observations:
(1) For development and debugging, FTN95 is as good as any, and better than most (assuming you do development and testing with a smaller dataset than you use for production!)
(2) FTN95 does use all the cores on a processor, because Windows makes it do so. Just look at a resource monitor screen. What you don't see is all the cores running at maximum speed - there is plenty else going on in the computer and this is the result of the hardware and OS design.
I think it is a mistake to equate the lack of explicit multithreading in FTN95 with "running on 1 core". As Windows does multithreading, then you would only fight it if FTN95 was trying to do it at the same time. I look to Paul for agreement here!

I am composing a discussion on the speed issue - I'll start a new thread for that because it is radically different to the 64-bit issue.

Eddie

DanRRight · Posted: Sat Mar 17, 2012 8:06 pm Post subject:

I do not have time but may be someone can start and support similar discussion in comp.lang.fortran to find the state of the art with 64bit compilers of all other companies? Interesting what is the main difficulty for devs?

Another issue. For some tasks I see potential temporal workaround by making 64bit part in different compiler and linking it with FTN95 with DLL. Can anyone try to make small sample code?

EKruck · Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany

Dan,

a nice idea, but, as far as I know there is no way to combine a 64-bit DLL with a 32-bit program.

Erwin

BillBardsley · Joined: 19 Mar 2012 Posts: 3

dpannhorst · Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany

I am still missing any comment / remark by Silverfrost!!??!!

What do they say to shorter update times of FTN95?

What do they think of supporting 64 bit Windows? Is there any schedule to do this?

It seems they don't like our discussions and therefore they will not give any answers to our (the users) questions.

Detlef

PaulLaidler · Posted: Thu Mar 22, 2012 2:22 pm Post subject:

Thank you for your input. It does help to know what our users would like to have. I am aware of this discussion and plan to respond shortly.

Paul

dpannhorst · Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany

Hi Paul,

did you give a reply already? I have nothing heard until now.

Detlef