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 

is v7.20 64-bit?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 889

PostPosted: Sun Apr 05, 2015 5:48 am    Post subject: Reply with quote

.. .what will be the delay before the v7.2 has a Personal version Paul ?

also, I'm confused about 64 bit.
I understand that the 64 bit compiler is still under development but I saw on another posts lots of talk about clearwin64.lib ? being included in v7.2, then in another post talk about intrinsics being in either salflibc64.dll or clearwin64.dll, etc....
It's confusing me a lot, as a dll / lib numpkin, as I jump between posts as to what's being talked about.
Total Confusion for me trying to follow what's what I'm afraid.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Apr 05, 2015 8:52 am    Post subject: Reply with quote

I will have to ask about a release date for the personal edition.

Clearwin64.dll was released some time ago. It allows you to use ClearWin+ with third party 64 bit compilers.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 889

PostPosted: Sun Apr 05, 2015 9:12 pm    Post subject: Reply with quote

Paul, last week you said:

Quote:
I think that the main focus is on jpg and png files but there may be others.
There is a reasonable chance that other image formats supported by GDI+ will work but I can not find a list of these via Google.

I will need time before I can give a more detailed response.


.... which got me searching.

FYI ......

I found this link:
https://msdn.microsoft.com/en-us/library/bb882579%28v=vs.110%29.aspx

which, although it is .NET specific - I don't think that's significant for the definition) indicates that GDI+ supported READ and WRITE (decode AND encode) formats are:-

BMP, GIF, JPEG, PNG, TIFF

while in addition GDI+ supports READ (encode) only for:-

WMF, EMF, ICON


I also found a link here with very clear definitions of image file formats:

https://msdn.microsoft.com/en-us/library/at62haz6%28v=vs.110%29.aspx


which answers very well the question:

"when is a JPEG/GIF/PNG/etc... not a JPEG/GIF/PNG/etc... ? ".

Something I'd not realised before, the answer is:
"when they're Bitmaps ! because they're ALL bitmaps, not just .BMP !"

which also explains the use of the distinguishing term DIB_* (although I'd obviously realised the reference to BMP files I'd never been sure of the significance of 'Device Independent' ) in the routines .
Which is in fact now incorrect since for a while other formats are no.w concerned; the routines should strìictly be renamed 'B_*' maybe !!! LOL Wink

I also see clearly now more of the advantages of GDI+ in this respect as you have simple to implement format output/conversion possibilities which I assume were 'built into CLEARWIN' previously, with all the associated 'maintenance' overheads to make sure they're always compatible with any format evolutions from M$ , .... or are these capabilities not only restricted to GDI+ ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Apr 06, 2015 8:35 am    Post subject: Reply with quote

Thanks for the feedback John. If anyone has any experience of using the latest ClearWin+ (GDI+) feature with the additional image formats mentioned by John then please let us know.

Previously the image formats supported by ClearWin+ were (for the most part) hard-coded with the attendant maintenance problems as formats evolved.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1972
Location: Sydney

PostPosted: Mon Jun 08, 2015 5:14 am    Post subject: Reply with quote

I was reviewing this post and I thought I would give some advice on moving to Windows 64 bit Fortran.

Even in 64 bit addressing there remain some significant limits (which can mostly be overcome) : CODE and COMMON are still restricted to 2gb.

There are others, but these are the main ones referenced.

I don't know much of the CODE restriction, as I have never approached the 2gb limit for CODE and I suspect few others ever will. ( My CODE usage is typically less than 2mb )

COMMON can be a restriction for easily changing old legacy codes for larger data sets.

The way to overcome COMMON is to use ALLOCATE for large arrays. Typically these can be placed in a MODULE for global scope. There is no alternative, BUT, you will find this to be a very effective approach, as arrays can be allocated then deallocated when not required. You may find you need less memory!

There have been some improvements to ALLOCATE since Fortran 95, such as calling subroutines with an allocatable argument, but for those familiar with pre F90 memory management, the main failings of ALLOCATE is you can't allocate a very large array (the rest of memory!) then resize it when you know how big it has to be. (this can be overcome by duplicating the array or MOVE_ALLOC)

I think it is a good coding approach to move to using MODULES with ALLOCATE variables.

Another useful concept to understand is how much memory should be used. You need to understand.
Addressable memory limit : I don't know what it is but it is not important for now.(we said that when changing from 16 to 32 bit) It might be 128gb or more (8Tb).
Physical memory limit : The amount of memory installed in your PC (or the PC likely to run the program ) The run time performance declines as this is approached. It is a good practical limit.
Virtual memory limit : The size limit of pagefile.sys. Typically larger than physical memory but surprisingly not always! When the memory required for your program and all other programs running exceeds physical memory, some memory image (pages) are written to "disk" to pagefile.sys. This slows down all programs running, depending on the page fault rate (memory pages transferred per second). Simplistically, the memory usage of all programs running cannot exceed the size of pagefile.sys, so this places a practical limit on the memory your program should use.
Array addressing limit : If you use Integer*4 subscripts, your array can not have more than 2^31 elements, so you need to change to I*8 subscripts for very large allocated arrays. This means real*8 arrays larger than 16gb, so not an initial problem.
Stack size : The stack size is typically limited to 1gb, so the use of large local (automatic) arrays can be a problem. Replace these with ALLOCATE is a good approach for moth 32-bit and 64-bit coding.
Cache size: Cache size is about 6mb to 10mb. While not a 64-bit limit, addressing large rank arrays the “wrong” way can lead to cache clashes and slow performance. Bigger arrays have bigger problems. All the virtual memory strategies of 70’s and 80’s remain important for good performance, as ignoring this can have dramatic performance results, forget about chasing 2x or 4x with SSE or AVX instructions; bad memory addressing can cause 10x to 100x or more performance penalties.

BLOCK DATA and initialising arrays in declaration statements. While Initialised data can be a simple approach, for large arrays, do it in an executable statement. I rarely initialise arrays in an initialisation statement and for ALLOCATABLE TYPE arrays, prefer an initialised TYPE element that I apply to the array as an executable statement.
Be aware, for large arrays, memory is not taken at ALLOCATE but when the array is used/initialised, which can defer memory availability errors occurring for very large arrays.

If you want to test FTN95_64 successf
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Jun 12, 2015 4:30 pm    Post subject: Reply with quote

John,

You got caught by the max post size limit.

I suspect that even the fastest cpu you can buy will struggle to run other programs at the same time as anything big enough to demand 64-bit addressing, so there isn't all that much point in running it in other than on a dedicated computer.

Eddie
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1972
Location: Sydney

PostPosted: Sat Jun 13, 2015 10:09 am    Post subject: Reply with quote

Eddie,

Quote:
I suspect that even the fastest cpu you can buy will struggle to run other programs

That is not the case. I have a 2-core i5 with 8gb memory and am running 64-bit OpenMP tests up to 7.5gb and it runs very well. I even ran a 15.5gb test, which thrashed the paging and it ran sort of ok. I am looking to manage out of core for these large problems, using 64-bit, to compare windows paging with an solver algorithm for paging to see the difference.

When writing the review of 64-bit, I am reminded when changing from 16-bit to 32-bit in about 1993. At that time, 2gb looked to be huge. Although I was reluctant to change (to a new compiler) I soon relished the simplicity of not using an overlay linker, or describing arrays larger than 64kb as HUGE.

At the moment I am moving to a 16gb memory pc. A colleague is using 96gb, although my real limit is how much memory I am prepared to buy.
I found the BBC programs on computer languages very interesting. I wonder where programming will be in even 10 years.

I am impressed that 20 year old Fortran 95 with Allocate appears to provide a good platform for 64-bit computing. FTN95 is my main development compiler, even for 64-bit; I just start with smaller test examples. I am putting error tests on all ALLOCATE commands, although these will probably not be needed for a 64-bit compiler.

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



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

PostPosted: Sat Jun 13, 2015 11:21 am    Post subject: Reply with quote

John,

You missed the point(s).

1. The end of your previous post is still missing.

2. The 'other programs' can't be expected to run at the same time as the memory hogger, thus negating part of the point of Windows. (And not that the memory hog won't run at all. Of course it will. It rarely chews more than a few bites at any time - pun intended - and if you give it long enough it will munch through the lot.) And 8Gb isn't all that big - what about the 192 Gb monster you once mentioned. I'll bet that chomping through a matrix inversion that takes most of that isn't going to allow you to do your e mail, photo editing, Facebook and heaven knows what all at the same time.

Eddie
Back to top
View user's profile Send private message
dgurok



Joined: 26 May 2011
Posts: 38

PostPosted: Tue Jul 28, 2015 3:11 pm    Post subject: Reply with quote

Paul,

do you have some new information related to a first 64 bit version? We are very interested in it and some new information would be great. Do you think a first release of a 64 bit version this year is realistic?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jul 28, 2015 10:32 pm    Post subject: Reply with quote

We are aiming to release a beta version of 64 bit FTN95 before the end of 2015 and at the moment this seems to be a realist goal.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Jul 29, 2015 12:07 pm    Post subject: Reply with quote

I remember that the first estimation last year was about March-April of this year. Then we heard that you guys already were testing and benchmarking it. And now the date slips for 6 months. Or more as this will be only a beta?

What a holly wait

<here deleted was a story of my 20 years polite requests to Salford if they plan to make 64bit compilers and the ones for the supercomputers...>
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 944

PostPosted: Wed Jul 29, 2015 5:30 pm    Post subject: Reply with quote

Keeping the following aphorism in mind, I don't have any complaints.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

—Tom Cargill, Bell Labs
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Jul 29, 2015 10:11 pm    Post subject: Reply with quote

Will add: and be sure that the final 1% of the code and the code validation will stretch out of you another 90% of development time. At your own personal time expenses.

LOL That factor of 3 will be more precise universal estimation...
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
Page 2 of 2

 
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