Christian Bell wrote:
I agree with Joe that as the shared memory system scales, the once
subtle potential cache coherency problems can become quite an impediment
to performance. However, I'd think (or at least hope) that we could
agree on the simpler things, like read-only text.
[note to se
On Tue, 14 Apr 2009, Joe Landman wrote:
Why is sharing expensive in performance? It might take a little
overhead to setup and manage, but why is having multiple virtual
addresses map to the same physical memory expensive?
Contention. Memory hot spots. Been there, done that. We are about to
Jon Forrest wrote:
But this wouldn't happen in the scenarios you describe
because text is read-only. There would be no updaters or writers
or any kind of contention. The text pages would have to get filled
Ok, lets assume you have a table in the text, that every thread is using
to dereference
Joe Landman wrote:
Imagine you are a processor, and you have written to a location in ram.
So now your cache line is dirty, and waiting in queue to be flushed
out. In your parallel program, along comes someone else who really,
really wants to read that cache line. Ok, so this forces you to
Jon Forrest wrote:
Joe Landman wrote:
... so I see you have never used an interprocedural analysis (-ipa)
switch :)
Allows you do do things like, I dunno, inline one whole routine inside
another ...
I've never used this but from your description I don't
see how it leads to larger text size
Joe Landman wrote:
... so I see you have never used an interprocedural analysis (-ipa)
switch :)
Allows you do do things like, I dunno, inline one whole routine inside
another ...
I've never used this but from your description I don't
see how it leads to larger text sizes at runtime. After
Jon,
The size of the final source code for a program is not really relevant to
human comprehension, because we chunk it. FORTRAN makes it possible for the
engineer to comprehend a program that would be inaccessible to him as the
equivalent (very long) list of Assembler statemtents; how far would y
Jon Forrest wrote:
that compilers will never try to unroll code at that level, even when
enormous memory systems are commonplace?
Again, the enormous memory systems you mention consist mostly
of enormous amounts of data, not text.
... so I see you have never used an interprocedural analysis
Run Forrest -- Run!
Steven A. Herborn
U.S. Naval Academy
Advanced Research Computing
410-293-6480 (Desk)
757-418-0505 (Cell)
-Original Message-
From: beowulf-boun...@beowulf.org [mailto:beowulf-boun...@beowulf.org] On
Behalf Of Greg Lindahl
Sent: Tuesday, April 14, 2009 2:25 PM
To: beo
Robert G. Brown wrote:
Are you
suggesting that e.g. a long-running program with fully unrolled loops
cannot exceed 4 GB in size and still be "simple"?
Unrolled loops probably add only a few percent to the text size
of a program. I admittedly don't have any data to prove this
but try to imagine
On Tue, 14 Apr 2009, Jon Forrest wrote:
The reason for this is that it's simply too hard to write
a program whose instructions require even close to the
32 bit address space. Such a program would be too complex
to understand, assuming it's written by humans. Maybe
I'm not sure what you mean he
On Tue, Apr 14, 2009 at 10:55:22AM -0700, Jon Forrest wrote:
> I claim that there's a memory-related constant that hasn't been
> widely recognized. This is that the amount of address space for
> a program's text segment will never exceed 32 bits. Note that
> I am *not* talking about the data segme
Joe Landman wrote:
We know of (and have worked with) many applications that have required
tremendous memory footprint. One that required hundreds of GB of ram in
the late 90s might use a bit more today.
I claim that there's a memory-related constant that hasn't been
widely recognized. This i
On Tue, 14 Apr 2009, Steve Herborn wrote:
As far as "Desktop" machines go there hasn't been an application invented
that needs more. Because memory & disk storage prices fell programmers got
sloppy & crammed in a lot more, but little to none of it was actually an
application that truly needed m
Steve Herborn wrote:
As far as "Desktop" machines go there hasn't been an application
invented that needs more. Because memory & disk storage prices fell
H.
programmers got sloppy & crammed in a lot more, but little to none of it
was actually an application that truly needed more
All,
MSI is seeking qualified candidates for the Institute's Director. Please
see below and share.
--
Director of the Supercomputing Institute for Advanced Computational
Research and Tenured Faculty Member at the University
As far as "Desktop" machines go there hasn't been an application invented
that needs more. Because memory & disk storage prices fell programmers got
sloppy & crammed in a lot more, but little to none of it was actually an
application that truly needed more because of purpose, only poor design.
Almost exactly four years ago Gordon Moore himself predicted his own law's
demise.
Moore said: "It can't continue forever. The nature of exponentials is that
you push them out and eventually disaster happens."
Steven A. Herborn
U.S. Naval Academy
Ad
David N. Lombard wrote:
On Sun, Apr 12, 2009 at 10:53:09AM -0700, Matt Lawrence wrote:
On Sat, 11 Apr 2009, Залетнев Дмитрий wrote:
I have a motherboard with 4x SATAII-ports and without RAID. If I'll
connect to these ports 4 identical SATAII 250 GB 7200 rpm HDDs and
install Linux, is it possi
On Sun, Apr 12, 2009 at 10:53:09AM -0700, Matt Lawrence wrote:
> On Sat, 11 Apr 2009, Залетнев Дмитрий wrote:
>
> > I have a motherboard with 4x SATAII-ports and without RAID. If I'll
> > connect to these ports 4 identical SATAII 250 GB 7200 rpm HDDs and
> > install Linux, is it possible to have
20 matches
Mail list logo
