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 

FTN95 Version 8.3 - Some Initial Observations
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 480
Location: Morrison, CO, USA

PostPosted: Mon Mar 26, 2018 9:03 pm    Post subject: Reply with quote

I never thought it was particularly slow.

That said, it is much faster. I spend a LOT less time waiting for my full rebuild now. Makes me happy!!
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 480
Location: Morrison, CO, USA

PostPosted: Thu Mar 29, 2018 9:49 pm    Post subject: Reply with quote

OK, here's something strange as of 8.30. I never saw this running the 8.20 version, and, yes, I did look!

I compile/link both a /CHECKMATE and a /RELEASE version of my software during the build process.

Using the CTRL-SHIFT-ESC to get the Task Manager up to look at resources consumed when I run the programs, the /CHECKMATE compilation consumes about 685 MB of memory, while the /RELEASE compilation consumes 24.5 MB. I know the 24.5 MB is "incorrect": because I have very large common blocks that exist in BOTH compilations.

As I run through various parts of the /RELEASE variety, the amount of main memory begins to climb. It is as if the memory is NOT being allocated for those common blocks until such time as I access those data, where the/CHECKMATE variety has it all loaded, all the time.

Nothing is amiss in the /RELEASE variety; everything works great.

FYI: The .bss section in the link map shows 674,303,196 bytes for /RELEASE and 712,995,816 for /CHECKMATE. Expected, I guess, because /CEHCKMATE needs some more data storage for "stuff".

Just an observation on my part. Wondered what others might have seen?
Bill
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1997
Location: Sydney

PostPosted: Fri Mar 30, 2018 2:04 am    Post subject: Reply with quote

Bill,
I think what you are describing for Release has always been the case.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 480
Location: Morrison, CO, USA

PostPosted: Fri Mar 30, 2018 5:45 am    Post subject: Reply with quote

John, thanks for the update.

I'd never seen that for /RELEASE. Not that it doesn't happen; the program I normally would have looked at uses a LOT of main memory from the start, so I may have just never seen it.

Bill
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1024

PostPosted: Fri Mar 30, 2018 11:47 am    Post subject: Reply with quote

It is to be expected that /checkmate would force allocation of memory at the outset. Uninitialized variables, including some big arrays, have to be filled with special values so that, when the same variables are used later, their values can be compared with the special value to detect whether they have been initialized.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Mar 30, 2018 12:40 pm    Post subject: Reply with quote

ALLOCATE for 32 bit /CHECK uses its own memory allocation based on existing blocks of VirtualAlloc memory and sets to the "undefined" state when called.

ALLOCATE for 64 bit /CHECK uses GlobalAlloc/HeapAlloc and sets to the "undefined" state when called.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 480
Location: Morrison, CO, USA

PostPosted: Sun Apr 01, 2018 12:13 am    Post subject: Reply with quote

Thanks for the explanation, Paul.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Mon Apr 02, 2018 12:28 pm    Post subject: Reply with quote

Please go to the following post regarding new DLLs...

http://forums.silverfrost.com/viewtopic.php?p=24394#24394
Back to top
View user's profile Send private message
dpannhorst



Joined: 29 Aug 2005
Posts: 157
Location: Berlin, Germany

PostPosted: Fri Apr 06, 2018 7:03 pm    Post subject: Reply with quote

The dropbox link to new dlls leads to an error.

Detlef Pannhorst
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Fri Apr 06, 2018 7:08 pm    Post subject: Reply with quote

Yes. The above link explains why the download has been removed.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon Apr 09, 2018 7:38 am    Post subject: Re: Reply with quote

wahorger wrote:
I am observing that V8.30.0 is much faster at 32-bit compiling than 8.20.0.


All version were always superfast like no other compiler, i automatically keep compilation speed results from 1999. Where other compilers spend 3 min FTN95 compiles 3 seconds. That takes place many times per day. And since during program development (in my case this is vast majority of spent time) the compilation and debugging speed are key, they are way more important then run time. Usually people say that they chose Fortran for its run speed. But this without parallelisation and supercomputers is an absurd. In reality if they use PC they lose most of the time for development. Lose just 3 seconds per day and at the end of life you will lose 24 hours. Actually we lose many many hours per day, how much this end up for life is even scary to pronounce.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Apr 09, 2018 10:59 am    Post subject: Reply with quote

Please go to the following post regarding new DLLs.

http://forums.silverfrost.com/viewtopic.php?p=24467#24467
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1997
Location: Sydney

PostPosted: Mon Apr 09, 2018 1:29 pm    Post subject: Reply with quote

Dan,

Ver 8.3 provides more multi-threading options.
I am looking to see what I can achieve and will update shortly.

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



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

PostPosted: Mon Apr 09, 2018 10:09 pm    Post subject: Reply with quote

Interesting, would like to look, but i'm too busy now to experiment. Meantime for you, John, Paul and those who already started i have few questions about this parallel method:

1) What's new here compared to previous method which allowed to start parallel threads?

2) Was the LOCK mechanism implemented like in FTN95 for NET allowing to print without danger of threads crash? This is the big problem during debug because of a lot of I/O happen at this time

3) How fast is this method compared to parallel example for NET i posted few years back (see the link below, use my last demo) which showed amazing unexplainable till now more then 6.2x speedup on typical 4-core 8-thread processors ?

4) Anyone already bought new cheap 8, 16 or even 32-core AMD processors? How fast is the method on AMD vs Intel

Here is URL for FTN95 for NET case.
http://forums.silverfrost.com/viewtopic.php?t=2534&highlight=net+multithreading
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1997
Location: Sydney

PostPosted: Tue Apr 10, 2018 3:47 am    Post subject: Reply with quote

Dan,

Interesting questions, but I will try to answer a few of my own first.

Why try using AMD when intel are so cheap ?
I just bought an i7-8700K which has 6 cores for 12 threads. The important feature is it supports 2666 MHz memory, which provides a greater memory transfer bandwidth. It gives noticeable improvement in comparison to i7-4790K for multi-thread equation solution of 300 Mb skyline matrix for 12 threads. The 4790K (4 cores, 8 threads) looses efficiency above 4 threads when hyper-threading, which I attribute to the slower 1600 MHz memory.

My use of multi-threading is fairly basic. The FTN95 approach does require some care when managing private variables. My approach is to immediately call a routine, which then allocates local variables for all private variables, while shared arrays are allocated before thread initiation to provide thread based accumulators. (even the thread ID must be private !) I am now trying to emulate SCHEDULE(DYNAMIC) and CRITICAL.
FTN95 threading could offer a lot of potential, as opening an OMP PARALLEL region can take 30,000 processor cycles on other compilers, which kills small load threads.
Still have some work to complete this approach,

John
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, 3  Next
Page 2 of 3

 
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