forums.silverfrost.com

silverfrost · Posted: Mon Oct 27, 2014 9:30 am Post subject: 64-bit FTN95

In order to allow ClearWin+ users to run their code in 64-bit mode we
developed a 64-bit ClearWin+ DLL that can be used with other FORTRAN
compilers. This is included in FTN95 today and some users have made use of
it to run their code in the CPU’s native 64-bit mode.

The 64-bit ClearWin+ DLL is a stop gap solution until we complete the work
on our own 64-bit compiler. We plan to complete this work in 2015 and
deliver a full 64-bit FORTRAN compiler.

DanRRight · Posted: Mon Oct 27, 2014 9:52 am Post subject:

Wow, that was the great great great news. Please do not lose your speed on fixing of possible bugs of current compiler! Will be glad to pay in advance and betatest

Wilfried Linder · Posted: Mon Oct 27, 2014 12:01 pm Post subject:

These are very good news indead!

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

Hopefully it is not to late and you have not lost too much customers in the meantime to Intel!

Just in March 2012 other customers and me asked to hurry up the development of a 64 bit compiler (see topic "Again: 64 bit Compiler" in this forum).

I hope this version will be available in early 2015. It is needed urgently!

Regards, Detlef Pannhorst

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

This is good news and I look forward to the updates.
Should you need any testing, I would be pleased to help.
I do have a few large memory testing programs, mainly related to numerical calculations.

64-bit is basically 32-bit and allocate.

One of the important changes that has accompanied 64 bit has been vector instructions. I use the SSE routines with FTN95, as these have allowed me to maintain performance in comparison to ifort and gFortran.

The convenience of maintaining existing clearwin code in a 64-bit environment will be a great improvement.

John

DanRRight · Posted: Tue Oct 28, 2014 1:39 am Post subject: Re:

John-Silver · Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley

This is good news (I think), however .....

Can we also expect somtime between now and 2015 to have a SimplePlot64 also ? :O)

Can we also maybe have an update to ftn95express which includes the latest ftn95 version (not 5.4) and which installs correctly on all machines/Os's,

Or are these fundamental (imo) things going to be forgotten in all the hype that is 64-bit development ?

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

Dan,

With 64 bit code, the 2gb code restriction is due to the .exe format restriction. It is not a limit that will impact us.
Using ALLOCATE in MODULES is an easy change to get use to. It encourages more flexibility in problem definition.
I typically have just a few large arrays, which cause all the problems.

An area where FTN95 will need to pay more attention is with KIND, so that pointers and address references will need to change to Integer*8. LOC will change and I am not sure how CORE routines will change.
It may be worth reviewing some of the F2003 and F2008 changes. Adopting ISO_Fortran_Env (2008) and ISO_C_Binding could be a useful way to future proof the changes required for ftn95 /64. I am not suggesting developing lots of the new features of F2008, but some of the changes do show a way of supporting both 32-bit and 64-bit in a more systematic way.
I am sure we all have a wish list of new Fortran features, although getting FTN95 /64 available should be the first priority. (there are a few intrinsic functions I'd like available!)

John

PaulLaidler · Posted: Wed Oct 29, 2014 9:00 am Post subject:

Thanks John. Perhaps you could remind us of some of these issues after the initial trials. Others hopefully will have already been addressed.

DanRRight · Posted: Wed Oct 29, 2014 4:18 pm Post subject:

John, I currently use that exactly approach and it generally works OK. But this is because we are at the times when 2GB is considered a lot. It will be nothing as soon as next year after you start driving 64bit compiler. By the way I still do not like to mess with allocation/deallocation. And when your code growing and growing at some point all static allocation area will be used with the code not just arrays.

So who hardcoded 2GB limit, is it iFort or Microsoft? If it is hardcoded in the compiler we will end up with the same "640K is good for everyone". Imagine how ridiculous this could be today. If this is Microsoft then i hope they will remove it in the future. Again if this is due to Intel Ifort restrictions and now all following it then my suggestion is that the new Silverfrost 64bit compiler should definitely avoid it and not hardcode the 2GB limit and of course remove all stack limits of former compiler (200MB or so) which made so much headache in the past

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

Dan,

My impression is that the 2gb limit is a Microsoft limit, due to the nature of the .exe format.
There are two areas where the 2GB limit applies.

1) The 2gb limit on static variable allocation can be overcome by using ALLOCATE. This means that COMMON must be migrated to MODULE with ALLOCATE for larger arrays. I find this approach better and don't use COMMON in new code. The big change here is that EQUIVALENCE is no longer available, which has meant some changes for old non-standard code. The TRANSFER intrinsic can overcome some of these problems. I still have lots of mixed mode and mixed KIND error reports in subroutine calls, as I change the type of variable. I am gradually moving away from my old Fortran 66 record structures, but they all still work well.

2) The 2gb limit on code is a limit I don't expect to have any trouble with, as my code is no where near that limit. I doubt if you will have any trouble with this either.

One of the interesting changes with 64-bit is when you use more virtual memory than there is installed memory. You go back to using paged memory. Everything stops! It's horrendous! This is how we ran programs all the time in 70's and 80's and thought it was working well. Shows how quickly we forget and only remember the good times.

64-bit is not an excuse to be lazy, as poor memory and cache usage have a huge performance penalty, as we have seen with the equation solver examples last year. The virtual memory programming strategies are still very important.

John

John-Silver · Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley

Just a small point here.
!. Shouldn't this 'announcement' have been in the , err, Announcements Forum ?
2. If it's possible, it would be a good idea to seperate 64-bit discussions onto a seperate Forum wouldn't it ? (I think I suggested this for the previous post about 64bit which is posted somewhere and became tortuously wrong and included loads of different topics.

DanRRight · Posted: Thu Oct 30, 2014 9:21 am Post subject:

John,

ALLOCATE is a bit different concept while it is obvious that static allocation being less capable still will never die if not make it die with 2GB restrictions. It is obvious that the array sizes will grow and grow and grow 2^32 times or 4 billion till the 64bit will be exhausted. Tiny fly still has memory size way larger than that Smile

So why kill it with stupid 2GB restriction? Static allocation is convenient and in many cases is completely sufficient for the code. Plus there are a lot of legacy programs which use it. Such programs will be used for a century at least. One of arguments against common blocks was that it is potentially susceptible to bugs. But exactly this compiler with its super diagnostics made this completely a non-issue.

Static allocation has potentially one killing application which was developed by this compiler developers for FTN77 and which becomes again extremely relevant with 64bits - virtual common. If your matrix is sparse you declare arrays the size you want till these gazillions of heaxabytes 64bit limit allows and compiler allocates only those memory cells which are actually used. That allows very convenient, transparent, simple methods of solution where you make easy maintainable and modifiable code which will have less bugs. You can not do that easily with ALLOCATE, that will require completely different much more tricky methods and sometimes there are no workarounds and you will end up buying tons of memory to run the code

Is virtual common in the supported feature list for 64bit compiler?

BTW if Microsoft made this 2GB restriction then it will be automatically lifted when there will be no 32 bit OSes and we have nothing here to argue about. I do not like that compiler developers make these restrictions.

PaulLaidler · Posted: Thu Oct 30, 2014 9:29 am Post subject:

Dan. This is a good question and one that I don't have an immediate answer for.

May I suggest that these questions be raised after the initial beta release so that we can focus on getting that done as soon as possible.

DanRRight · Posted: Thu Oct 30, 2014 9:51 am Post subject:

Paul, I do not know what path you guys pursue in 64bit compiler development -- is it same FTN95 with only workaround from 32 to 64bit or complete redesign from scratch. In last case it is important to plan new features very early in the development plan. I afraid that if 64bit compiler will miss such trendy things like parallelization with OpenMP or CUDA, or Ifort compatibility it will be much less used by mainstream users.