View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Mar 26, 2018 9:03 pm Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Mar 29, 2018 9:49 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Mar 30, 2018 2:04 am Post subject: |
|
|
Bill,
I think what you are describing for Release has always been the case. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Mar 30, 2018 5:45 am Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Mar 30, 2018 11:47 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Fri Mar 30, 2018 12:40 pm Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Apr 01, 2018 12:13 am Post subject: |
|
|
Thanks for the explanation, Paul. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
|
Back to top |
|
|
dpannhorst
Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany
|
Posted: Fri Apr 06, 2018 7:03 pm Post subject: |
|
|
The dropbox link to new dlls leads to an error.
Detlef Pannhorst |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Fri Apr 06, 2018 7:08 pm Post subject: |
|
|
Yes. The above link explains why the download has been removed. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Mon Apr 09, 2018 7:38 am Post subject: Re: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Apr 09, 2018 1:29 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Mon Apr 09, 2018 10:09 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Apr 10, 2018 3:47 am Post subject: |
|
|
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 |
|
|
|