gfortran, g95, and dual-core 
Author Message
 gfortran, g95, and dual-core

Can gfortran or g95 gain anything from dual- or multi-core processors in
either speed of compilation or speed of execution?  Does anything
besides clock speeed matter much?


Thu, 18 Mar 2010 01:32:49 GMT  
 gfortran, g95, and dual-core

Quote:

> Can gfortran or g95 gain anything from dual- or multi-core processors in
> either speed of compilation or speed of execution?

If nothing else, having a multiple cores allows mltiple processes to run
at the same time. This is, of course, an issue that has come up decades
ago with multi-processor archiertctures long before the current cop of
multi-core processors. Even on a single-use machine, you at least get
some benefit in that your program can get all of a core, while other
overhead stuff (such as the operating system and graphics user
interface) can use the other. That's overly simplified, just for
illustration of the idea.

Quote:
> Does anything
> besides clock speeed matter much?

Um. Wow! That's a loaded question, and one that people spend whole
careers on. I think you just asked what matters in terms of program
performance. Perhaps you meant it in a more narrow sense. If so, I
missed it.

Many, many things matter. The details are complicated and vary widely as
a function of just about everything, probably including the phase of the
moon.

Today, many programs are limitted by memory bandwidth, which is
typically (mostly) independent of CPU clock speed. That's why cache is
such a big deal and spawns a large number of issues about taking best
advantage of cache.

Disk I/O can also be a big deal fo some programs (notably including
compilers). Sometimes using large amounts of memory can help lower disk
accesses to addres that issue.

And, of course, to pull out that old cliche - but one that is so true -
a good choice of algorithm usually matters more than anything else.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain



Thu, 18 Mar 2010 01:39:32 GMT  
 gfortran, g95, and dual-core
Quote:

> Can gfortran or g95 gain anything from dual- or multi-core processors in
> either speed of compilation or speed of execution?  Does anything
> besides clock speeed matter much?

gfortran, since 4.2, supports OpenMP parallel compilation (but
apparently not for mingw).  make -j can give a big jump in build
performance, worth doing even if you are a Windows fanatic.
Not sure what you have in mind when you say "anything."  Recent linux
distros do an improved job of default scheduling on multi-core, often
relieving you from fiddling with taskset and the like.  Windows fanatics
rely on low level affinity calls, not what I like to do with Fortran.
Quad cores with the lowest available buss speeds saturate quickly on
memory operations with parallel programming.  The buss clock speed is
more important then than the CPU clock speed.


Thu, 18 Mar 2010 01:45:46 GMT  
 gfortran, g95, and dual-core

Quote:
> Can gfortran or g95 gain anything from dual- or multi-core processors
> in either speed of compilation or speed of execution?

Speed of compilation: if you compile single source files, there probably
isn't anything to gain. If your code has multiple source files, it will
depend on your compilation process, but if you use a decently written
makefile, you will gain.

For execution speed, there are two ways to go. The standard way to get
there is to parallelize the code yourself, either with MPI (probably
requires costly and invasive changes, but will work for distributed
memory systems as well as the multicore scenarios), which can work with
any compiler, or OpenMP. OpenMP is less invasive, you can quickly
parallelize a few hot spots in your code in under an hour (make that a
few hours, if it's your first time), but it requires compiler support,
which gfortran has but g95 hasn't.

The other way is to not touch your code at all, and ask your compile rfor
autoparallelization. Gains from this will usually be relatively small,
but you have little to lose. This also requires support from the
compiler, which is not present in g95, and will be present in gfortran
only starting with the next release series (4.3.x). For more information
about autoparallelization, others might know more than what I said above.

PS: Of course, if your code heavily relies on external libraries, it
could be as simple as using a parallel version of the libraries.

--
FX



Thu, 18 Mar 2010 02:06:18 GMT  
 gfortran, g95, and dual-core

Quote:
> gfortran, since 4.2, supports OpenMP parallel compilation (but
> apparently not for mingw).

Yes it does support OpenMP on Windows, providing that a POSIX thread
library is available. As an example, the Windows binaries of gfortran
regularly built and available at http://gcc.gnu.org/wiki/GFortranBinaries
include OpenMP support (using the pthreads-win32 library, provided in the
installer).

--
FX



Thu, 18 Mar 2010 02:08:43 GMT  
 gfortran, g95, and dual-core

Quote:


>> Can gfortran or g95 gain anything from dual- or multi-core processors in
>> either speed of compilation or speed of execution?  Does anything
>> besides clock speeed matter much?
> gfortran, since 4.2, supports OpenMP parallel compilation (but
> apparently not for mingw).  make -j can give a big jump in build
> performance, worth doing even if you are a Windows fanatic.

The gnu make info file in my Cygwin distribution says that option -j is
ineffective with MS-DOS. Does it do anything under Cygwin?  What factor
is a "big jump?"

Quote:
> Not sure what you have in mind when you say "anything."

I should have been more specific.  First of all, I'm a scientific user,
not a programmer, so that most of your response is beyond my
understanding.  Since the first IBM PC, I've been accustomed to an
order-of-magnitude speed gain every time I replaced a computer, normally
about every 4 years, alternating between a minimal laptop and an upper
midrange desktop, so that one or the other was always less than 2 years
old. Two years ago was the laptop's turn, and I got the expected
order-of-magnitude gain.  Now it is the desktop's turn, but my
4.5-year-old desktop has a clock speed of 2.4 GHz, and even the top
range Intel chips are hardly any faster now. Instead, they have gone to
dual-core. Perhaps the market is all in laptops, so that high-speed
high-power chips are out of fashion.

What matters to me is not only execution speed, though that is
important, but also compilation speed, since my "user interface" is to
edit the source code.  With annually increasing clock speeds, I was
getting both.  The heavy lifting in my code is done with netlib
routines, so I simply want old code to run faster. The gain must be more
than a factor of 2 or 3 to matter much.  I had come to expect that much
gain every couple of years.

Can I gain anything by replacing my old PC?  If so, what are the
critical specifications when buying a mid-price-range PC for crunching
numbers with fortran?

My original question was more general because I was also curious how
serious fortran programmers expect to deal with the changing trend in
chip development, but the answers are Greek to me.

  Recent linux

Quote:
> distros do an improved job of default scheduling on multi-core, often
> relieving you from fiddling with taskset and the like.
 > Windows fanatics
> rely on low level affinity calls, not what I like to do with Fortran.
> Quad cores with the lowest available buss speeds saturate quickly on
> memory operations with parallel programming.  The buss clock speed is
> more important then than the CPU clock speed.



Thu, 18 Mar 2010 03:03:05 GMT  
 gfortran, g95, and dual-core
Quote:

>> gfortran, since 4.2, supports OpenMP parallel compilation (but
>> apparently not for mingw).

> Yes it does support OpenMP on Windows, providing that a POSIX thread
> library is available. As an example, the Windows binaries of gfortran
> regularly built and available at http://gcc.gnu.org/wiki/GFortranBinaries
> include OpenMP support (using the pthreads-win32 library, provided in the
> installer).

In my installation of the 64-bit mingw binaries from the wiki, there is
no gomp specs file.  In my experience of building gcc on windows, this
is a normal consequence of not enabling libgomp in the build.
Evidently, a pthreads-win64 library would be required here.  OpenMP
support is not enabled in a default Windows build of gcc, although I do
always include it in my Cygwin builds.


Thu, 18 Mar 2010 03:35:30 GMT  
 gfortran, g95, and dual-core

Quote:

> The gnu make info file in my Cygwin distribution says that option -j is
> ineffective with MS-DOS. Does it do anything under Cygwin?  What factor
> is a "big jump?"

gnu make on Windows is not known for speed.  In my experience Cygwin
make -j 2, if not overdone, brings most of the relative speed increase
seen on linux.  I didn't to suggest make -j without supplying a numeric
limit.
Quote:

>> Not sure what you have in mind when you say "anything."

>  Now it is the desktop's turn, but my
> 4.5-year-old desktop has a clock speed of 2.4 GHz, and even the top
> range Intel chips are hardly any faster now. Instead, they have gone to
> dual-core. Perhaps the market is all in laptops, so that high-speed
> high-power chips are out of fashion.

Increasingly high power consumption, other than in desktop graphics
boards, has gone out of fashion.  My 5 year old P4 desktop board is
3.05Ghz, yet a 1.5 year old Core 2 board, stuck into another old P4 box,
out-performs it by about a factor of 4, including the gain from changing
from HT to dual core and from 32- to 64-bit OS.


Thu, 18 Mar 2010 03:49:25 GMT  
 gfortran, g95, and dual-core

Quote:
> In my installation of the 64-bit mingw binaries from the wiki

Oh, the Win64 binaries? I didn't enable OpenMP for these (though it
should be possible), as they are *really* experimental. Which is why
they're not on the wiki, and which is also why I didn't post a
comp.lang.fortran announcement yet. Now, the world knows ;-)

Quote:
> OpenMP support is not enabled in a default Windows build of gcc,
> although I do always include it in my Cygwin builds.

Yes, I always enable it in the binaries I distribute.

--
FX



Thu, 18 Mar 2010 03:51:56 GMT  
 gfortran, g95, and dual-core

Quote:


>> Can gfortran or g95 gain anything from dual- or multi-core processors in
>> either speed of compilation or speed of execution?

> If nothing else, having a multiple cores allows mltiple processes to run
> at the same time. This is, of course, an issue that has come up decades
> ago with multi-processor archiertctures long before the current cop of
> multi-core processors. Even on a single-use machine, you at least get
> some benefit in that your program can get all of a core, while other
> overhead stuff (such as the operating system and graphics user
> interface) can use the other. That's overly simplified, just for
> illustration of the idea.

The background activities on my Windows XP box are using only a few
percent of the CPU time, so I don't see much to gain there.  Vista may
be worse in this regard, as in so many others.

Quote:

>> Does anything
>> besides clock speeed matter much?

> Um. Wow! That's a loaded question, and one that people spend whole
> careers on. I think you just asked what matters in terms of program
> performance. Perhaps you meant it in a more narrow sense. If so, I
> missed it.

> Many, many things matter. The details are complicated and vary widely as
> a function of just about everything, probably including the phase of the
> moon.

> Today, many programs are limitted by memory bandwidth, which is
> typically (mostly) independent of CPU clock speed. That's why cache is
> such a big deal and spawns a large number of issues about taking best
> advantage of cache.

Had to look up cache in Wikipedia. I presume you are talking about what
they call "CPU cache".

So computing time is not simply a matter of counting "flops" (defined in
Golub & Van Loan "Matrix Computations" (1983) as the cost of "a floating
point add, a floating point multiply, and a little subscripting")
because of the complicating factor of cache.  The simple model was so
much nicer.

Is this apt to make a big difference (factor of 2 in execution speed)
when comparing different Intel-compatible chips in a given price range?

Quote:
> Disk I/O can also be a big deal fo some programs (notably including
> compilers). Sometimes using large amounts of memory can help lower disk
> accesses to addres that issue.

I realized that disk drives matter for big problems that use virtual
memory, but I did not think about the compiler.

- Show quoted text -

Quote:

> And, of course, to pull out that old cliche - but one that is so true -
> a good choice of algorithm usually matters more than anything else.



Thu, 18 Mar 2010 04:38:17 GMT  
 gfortran, g95, and dual-core

Quote:


> > Today, many programs are limitted by memory bandwidth, which is
> > typically (mostly) independent of CPU clock speed. That's why cache is
> > such a big deal and spawns a large number of issues about taking best
> > advantage of cache.

> Had to look up cache in Wikipedia. I presume you are talking about what
> they call "CPU cache".

Yes, though other kinds of cace are also relevant. It's a big area.

Quote:
> So computing time is not simply a matter of counting "flops"

Nope. Hasn't been for decades. In many current situations, the time for
the floating point operations is almost negligable. Ok, that might not
be so 100% of the time, but it sure is the case a lot. I've been in this
business for... well... if I recall correctly, about the same amount of
time as you have. About 4 decades of programming experience in my case.
One thing I learned long ago was that the business is subject to change
- big changes. Things that are absolutely critical at one time become
largely irrelevant a decade or so later. Those people who don't adapt to
the changes quickly become irrelevant. I've known several people in that
situation.

It is not always just hardware changes either. There have been
breakthoughs in algorithms that have had fundamental impact far beyond
their obvious area.

Quote:
> Is this apt to make a big difference (factor of 2 in execution speed)
> when comparing different Intel-compatible chips in a given price range?

Yes.

Quote:
> > Disk I/O can also be a big deal fo some programs (notably including
> > compilers). Sometimes using large amounts of memory can help lower disk
> > accesses to addres that issue.

> I realized that disk drives matter for big problems that use virtual
> memory, but I did not think about the compiler.

If you had listened to the sound of the disk drive going wild while
compiling, as I often have done, you'd know that the compiler is often
very disk intensive. Mostly, I think that is because an optimzing
compiler can use huge amounts of memory, which can cause virtual memory
swapping. I'm not enough (or even very much) of an expert in compiler
innards to accurately explain all of what's going on. But as a user of
compilers, I can testify that it has often been very evident to me that
they were putting a heavy load on my disk drives and that compilation
speed tied pretty closely to disk drive speed.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain



Thu, 18 Mar 2010 04:44:48 GMT  
 gfortran, g95, and dual-core

   In my experience Cygwin

Quote:
> make -j 2, if not overdone, brings most of the relative speed increase
> seen on linux.

Are you speaking of a dual-core machine? Is that where the 2 comes from?

What does "overdone" mean?



Thu, 18 Mar 2010 05:12:28 GMT  
 gfortran, g95, and dual-core

Quote:

> If you had listened to the sound of the disk drive going wild while
> compiling, as I often have done, you'd know that the compiler is often
> very disk intensive. Mostly, I think that is because an optimzing
> compiler can use huge amounts of memory, which can cause virtual memory
> swapping.

Perhaps the reason I haven't noticed is that I always have all available
debugging features enabled, which probably switches off most of the
optimization. In fact, I don't recall using any compiler prior to g77
that did any optimization under those circumstances.


Thu, 18 Mar 2010 05:21:11 GMT  
 gfortran, g95, and dual-core
Quote:


>   In my experience Cygwin
>> make -j 2, if not overdone, brings most of the relative speed increase
>> seen on linux.

> Are you speaking of a dual-core machine? Is that where the 2 comes from?

> What does "overdone" mean?

Cygwin isn't tolerant of an unlimited number of make threads (make -j)
or even twice as many threads as pseudo-processors.  2 or 3 work fine on
a single core HT, for those of us whose 32-bit Windows boxes are long in
the tooth.


Thu, 18 Mar 2010 06:10:59 GMT  
 gfortran, g95, and dual-core


Quote:
> So computing time is not simply a matter of counting "flops" (defined in
> Golub & Van Loan "Matrix Computations" (1983) as the cost of "a floating
> point add, a floating point multiply, and a little subscripting")
> because of the complicating factor of cache.  The simple model was so
> much nicer.

        For an analysis of a fairly complex piece of software (in C++
rather than Fortran, but that's largely irrelevant) look at the paper
and/or slides here:

http://indico.cern.ch/contributionDisplay.py?contribId=259&sessio...
http://indico.cern.ch/contributionDisplay.py?contribId=490&sessionId=...

        For several reasons we're nowhere near to using the full capabilities
of our CPUs.

--
Ivan Reid, School of Engineering & Design, _____________  CMS Collaboration,

        KotPT -- "for stupidity above and beyond the call of duty".



Thu, 18 Mar 2010 19:51:35 GMT  
 
 [ 39 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. automatic arrays with negative size in g95 and gfortran

2. Common statement does not work with gfortran, but g95 gives the correct answer

3. gfortran or g95

4. gfortran vs. g95

5. difference between g95 and gfortran

6. g95 AND gfortran problem ONLY on PPC OSX Tiger

7. Compiler flags for compiling FEM2DLiB with g95 and/or gfortran

8. problem with very small numbers - g95 versus gfortran

9. g95 versus gfortran

10. Gfortran 2 years behind G95 and still not ready for prime time

11. Vector instruction support in G95 or Gfortran?

12. recl on g95 and gfortran

 

 
Powered by phpBB® Forum Software