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 

number crunching

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
weaverwb



Joined: 04 Aug 2005
Posts: 37
Location: Monterey

PostPosted: Mon Oct 31, 2005 2:38 pm    Post subject: number crunching Reply with quote

Hi,

I'm looking forward to moving some serious number crunching programs over to Fortran 90/95 from 77. Since they take so long to run (weeks on a fast PC), I'd like to use a pair of dual core processors to spread the work out. MPI would seem the best choice. Is there or will there be such a capability (third party?) for FTN95? Or high performance support? Since you generate coprocessor code (I assume that is 80-bit), I probably don't need 64-bit Fortran but do you expect that at some time?

I've been using Clearwin+ for my interactive programs so it would be nice to stay with the SilverFrost compiler.

thanks

Bruce Weaver
_________________
Bruce+Weaver
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 01, 2005 12:59 am    Post subject: number crunching Reply with quote

Bruce

There are no plans to extend the capabilities of FTN95 towards MPI or high performance Fortran. Some work has been done on a 64 bit version of FTN95 (i.e. providing a 64 bit address space) but there is currently no firm commitment to deliver this. The best you can get at the moment is a 3GB address space although it may be possible to increase this to 4GB on a 64 bit machine and OS.

FTN95 can deliver 80-bit extended precision real values under Win32 but the limitations of .NET allow only 64-bit real values.

If FTN95 does not provide the power that you require for number crunching, it may still be possible to use it (with ClearWin+) as a GUI front end.
Back to top
View user's profile Send private message AIM Address
weaverwb



Joined: 04 Aug 2005
Posts: 37
Location: Monterey

PostPosted: Wed Nov 02, 2005 9:07 pm    Post subject: number crunching Reply with quote

Hi Paul,

I may continue to loosely couple the cpus through occasional data sharing through the disk, which I believe only costs me a couple percent. This is less of a burden than dealing w/ two compilers all the time.

I have no use for .NET nor the 64-bit address space; my concern is with maintaining high precision without a large speed cost. I was thinking I would save a lot by having 64-bit registers. Is this true?

For FTN95 on a current 32-bit processor:

a. how much of a cost is there to load a double or extended precision floating point compared to single ?

b. what variable declarations and/or compiler options must I use in FTN95 to ensure the 80-bit model?

Thanks



Bruce Weaver
_________________
Bruce+Weaver
Back to top
View user's profile Send private message
Andrew



Joined: 09 Sep 2004
Posts: 232
Location: Frankfurt, Germany

PostPosted: Thu Nov 03, 2005 3:46 pm    Post subject: number crunching Reply with quote

In answer to b: In general there are no specific options required, FTN95 performs all internal floating point operations at 80 bit precision. With 80 bit precision it also allows for the use of READ(KIND=3) calculations. There are a couple of options to force precisions namely /DREAL, which forces single precision to double and /XREAL which forces all single and double precision variables to REAL(KIND=3).
Back to top
View user's profile Send private message
Anonymous
Guest





PostPosted: Thu Nov 03, 2005 9:42 pm    Post subject: number crunching Reply with quote

I use parallel libraries with Salford for a long time which allow to employ any amount of processors in parallel for solving all kinds of linear equations. Worked even with FTN77. Something is telling me (but I've not tried myself), that it is possible to interface also MPI with Salford too, if link it using wrapping utilities (made with other compilers which support MPI and which are link-compatible with Salford).
Also it is possible to "play" with some simplest parallel language in FTN77/95. I refer you to www.equation.com LAIPE and MTASK. You may ask the guy to recompile his libraries with latest Salford compiler (it is free now for personal use) , but I used them as CVF or MS fortran libraries SLINKed at the end and they worked OK. You can not debug these parallel routines, of course, because they are external, created by different compiler and optimized for speed, but it you need "nuclear engine" for rocket with ultimate speed, it is barely needed. Smile
Back to top
Anonymous
Guest





PostPosted: Thu Nov 03, 2005 9:53 pm    Post subject: number crunching Reply with quote

P.S. Will add, that 64bit and milticore computing becoming finally a hot issue.
Next year even laptops will be multicore Smile
Back to top
weaverwb



Joined: 04 Aug 2005
Posts: 37
Location: Monterey

PostPosted: Fri Nov 04, 2005 12:25 pm    Post subject: number crunching Reply with quote

Hi all,

Thanks for your useful comments.

I'm still struggling w/ a. Digging around for a few days on the Internet has made things even more confusing since there seems to be every combination of bus widths and register widths and operating system widths. I'm starting to wonder if there is much advantage to going to a 64-bit OS. Apparently not for the calculation part and various processors have various sized registers. How these registers (128-bit, 80-bit, 64-bit, ...) are used (x87, SSE3, ...) is, I guess, up to the compiler. Is the only advantage to a 64-bit operating system, for the purposes of number crunching, fetch speed (if that)?

On the other hand, standard timing tests I did show that a 3 Ghz 32-bit Pentium 4 were not much different than those on a 64-bit Xeon, both running under win2K. So if the caches keep up in 32-bit OS (?), what do I care? Do they? eeeek!

If anyone has some insight or experience in this, it would be greatly appreciated.

Thanks,

Bruce Weaver
_________________
Bruce+Weaver
Back to top
View user's profile Send private message
Anonymous
Guest





PostPosted: Sat Nov 05, 2005 3:03 am    Post subject: number crunching Reply with quote

64bit prosessors, OS and compiler will allow to extend address space beyond 2 GB. Waiting for that for decade (at that times you'd think people with such needs are just nuts, right?). Hope is that famous Salford "virtual common" mechanism is not thrown away (what means "common" in F90/95/2003 with its modular structure Sad )

Other advantages (order of percents or tens of percents) are too small to mention, compared to orders of magnitude in address space.
Back to top
weaverwb



Joined: 04 Aug 2005
Posts: 37
Location: Monterey

PostPosted: Sat Nov 05, 2005 12:04 pm    Post subject: number crunching Reply with quote

Hi S

Since I'll soon be committing to a couple years of developement here, let me be completely sure about what you're saying. The time cost for bringing in a KIND=2 or 3 from memory is comperable between the 32-bit and 64-bit modes for current 64-bit processors?

Memory size is a very long way away for me; my weeks-per-program-run is due to the number of stochastic iterations I must run in a large 2-D space. Although I'd like that space to be much larger, it would require about a year of run time at current one-thread, one-processor mode on a 3Ghz machine; even so I doubt it'd take more than 1 GB.

Bruce Weaver
_________________
Bruce+Weaver
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Nov 09, 2005 9:09 am    Post subject: number crunching Reply with quote

Bruce

With regard to your question a), modern processors are so complicated that the best way forward is to time a section of your REAL code embedded in a large outer loop so that it runs for at least 10 seconds (say). A comparison could then be made between the run times for REAL*4, REAL*8 and REAL*10.

REAL*10 will be the slowest.
Back to top
View user's profile Send private message AIM Address
weaverwb



Joined: 04 Aug 2005
Posts: 37
Location: Monterey

PostPosted: Thu Nov 10, 2005 3:56 am    Post subject: number crunching Reply with quote

Hi Paul,

After spending at least 3 days on the Internet trying to sort out the processors and their features, I have come to your conclusion about complexity. Intel in particular seems to have mixed and matched about every possible characteristic. the problem with the testing of my code is that it requires a number of available chip types and transport of the code between different compilers. On the other hand, I need no outer loop as running the code on a small section of spectrum takes about a week on a 3 Ghz Pentium 4.

Initial benchmarks (not my code) comparing a 64-bit Xeon and the Pentium 4 suggest only modest differences. I'm getting a dual core Opteron w/ both 32- and 64-bit Windows to test and I guess I'll have to try a 64-bit compiler as well. I'm completely committed to FTN95, Clearwin+ for my graphical interactive software now (Absoft didn't even have a way to read the mouse) but perhaps this crunching program I'm fretting about will need a different compiler. The only way to know is to do what you are suggesting: buy the compiler and make comparisons for my code.

Thanks,

Bruce Weaver
_________________
Bruce+Weaver
Back to top
View user's profile Send private message
Anonymous
Guest





PostPosted: Thu Nov 10, 2005 10:47 pm    Post subject: number crunching Reply with quote

I think memory archtecture, memory type, cache size, and
all that sort of things (and method of solution of course)
are comparable improvements to 32-to-64 transition.
In one word, its evolution. Two computers are basically
equal if they differ in performance by factor less than 2. The price
of both of them could be an order of magnitude difference Smile

If you need new quality, I'd think going to multi-processor computers
for your 2D/3D tasks. One, for example, with 4-8 cores -
already a *big* difference. Such multiprocessor multicore
motherboards are available, and next year will be cheap.
Back to top
Anonymous
Guest





PostPosted: Mon Jan 23, 2006 5:46 pm    Post subject: number crunching Reply with quote

I have experimented with real*10 vs real*8, using a finite element program of mine. I converted major chunks of my code to real*10, including the disk I/O routines and memory management. The main approach was to assemble the full stiffness matrix (equations) as real*10. I selected a shell element linear problem which gave poor numerical accuracy in real*8. When changing to real*10, the accuracy improved by less than 1 significant figure, based on the error estimate. There was also an increased run time, mainly due to the increased disk storage for the latger variables.
I concluded the benefit was minimal. The problem in performing this test is that a significant part of the equation solver aoppears to use a 80 bit accumulator, as it remains in the register, and so the improvement is minimal. Given the optimisation by the compiler and the use of 80 bit registers, it is hard to control what you are realy testing.
I am hoping for future benefits from extended memory addressing from 64 bit addressing to reduce the I/O delays which appear more significant with current P4 architecture in comparison to say 10 years ago.
The final warning is that it is hard to do experimental testing of performance as often the delays are difficult to identify. You could have your virus scanning software go off during the test and any result is possible !

Back to top
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
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