Re: gfortran, g95, and dual-core

Charles Russell <NOSPAM@xxxxxxxxxxxxx> wrote:

Richard Maine wrote:

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.

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.

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.

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
.

Relevant Pages

  • Re: Problem with INVD instruction
    ... :> I am using DPMI and GNU C compiler on Pentium 4 motherboard. ... :> I have a PCI card which is transfering data to main memory of PC using DMA ... In order to read physical memory address I am using farpeekl. ... My old data is in the cache because before actual DMA I fill memory ...
    (comp.lang.asm.x86)
  • Re: Problem with INVD instruction
    ... I am using DPMI and GNU C compiler on Pentium 4 motherboard. ... DJGPP Ring 0 => CWSDPR0.exe ... I have a PCI card which is transfering data to main memory of PC using DMA ... How did your 'old' data get into the data cache? ...
    (comp.lang.asm.x86)
  • Re: Broken ARM atomic ops wrt memory barriers (was : [PATCH] Add cmpxchg support for ARMv6+ systems)
    ... I would not remove the "memory" constraint in here. ... If you don't already know that smp_mbis always a compiler barrier then ... with partitioned caches, so that alternating cache lines are processed ...
    (Linux-Kernel)
  • Re: Manually optimizing for efficient cache usage
    ... > way to arrange my data structure to ensure very efficient cache usage. ... > (No compiler can do this for me, because this cannot be deduced at ... Windows lets me allocate such a large buffer, ... > but I'm afraid it is actually split in memory. ...
    (comp.lang.asm.x86)
  • Re: Pentium M differences: 1.73Ghz? 1.86? 2.0?
    ... the speed of the disk drives and even the memory is negligible. ... Virtually no task is ever executed entirely inside the CPU, and the minute that the CPU needs a single byte from the "outside world", it goes to memory. ... If the program in question OR the data being operated on is larger than the cache of the CPU, then the code and/or data have to be gotten from memory, and also probably an entire block of cache has to be written back to memory, and other blocks brought into cache from memory. ...
    (comp.sys.laptops)
Loading