Re: gfortran, g95, and dual-core

Richard Maine wrote:
Charles Russell <NOSPAM@xxxxxxxxxxxxx> wrote:

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.


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?

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.


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.


.

Relevant Pages

  • Re: is there a better XP Defrag..?
    ... but restricted to files that fit into the cache. ... And file access time can take up a significant ... system's disk access cache, but it doesn't really matter. ...
    (microsoft.public.windowsxp.general)
  • Re: [patch] x86, mm: pass in total to __copy_from_user_*nocache()
    ... Sure, it's "wrong", but does it actually matter? ... software almost never knows enough about the CPU cache to ... We use cached memory copies for everything ...
    (Linux-Kernel)
  • Re: Question on IDS 10 page size
    ... We have an OLTP database that we are moving to linux. ... I would prefer more opinions on this matter than just mine. ... Also this tends to isolate index pages from data pages preventing either from thrashing the other in to/out of cache. ... If yes, say because a large report pulls in a whole day/week/month's worth of data or warehouse apps access multiple day's data, then yes, larger pagesizes will likely improve performance for the same reasons that index performance is enhanced. ...
    (comp.databases.informix)
  • Re: Strange behaviour with constants, when multiple projects on the same code
    ... should differ only in target device and Conditional Compilation Constants.I ... have defined WINCE constant in WinCE project and PPC constant in PPC ... The problem is that no matter which project I try to build, ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: compilation and execution plan
    ... have event related to compilation, that's why we see only sp:cachemiss, ... the proc plan doesn't exist and fir the first execution ... > if you empty the proc cache. ... > next execution SQL Server will need to REcompile that plan. ...
    (microsoft.public.sqlserver.server)