From: nmm1 on 28 Dec 2009 09:23
In article <7prp55F4l6U1(a)mid.individual.net>,
Carlie Coats <carlie(a)jyarborough.com> wrote:
>> What I was referring to primarily was the way in which arbitrary
>> subsets of a single composite object become composite objects in
>> their own right, and the code that accesses them can't tell that...
>> Fortran could solve that by restricting parallel procedures to ones
>> with explicit interfaces, INTENT(IN) or INTENT(OUT) arguments, no
>> TARGET or VOLATILE ones, read-only modules, etc.
>Given your next-message inclusion of INTENT(INOUT), I can live
>with that. The style of Fortran that seems to be taught in
>meteorology departments probably could not.
Precisely. And meteorology is typical, in this respect.
From: Anne & Lynn Wheeler on 28 Dec 2009 09:52
Carlie Coats <carlie(a)jyarborough.com> writes:
> As one of those Fortran programmers, I think my biggest problem
> is trying to deal with external data formats designed by idiots.
> For an extreme example, have a look at the official World Meteorology
> Association standard for data interchange, GRIB. A readable starting
> point would be <http://dss.ucar.edu/docs/formats/grib/gribdoc/>.
> It has the most evil misalignment I've seen.
http://www.garlic.com/~lynn/2009s.html#23 Larrabee delayed: anyone know what's happening?
some x-over between ncar (national center for atomospherric research),
at ucar (university corporation for atmospheric research), and mesa
(table mesa drive).
in the early 90s, congress passed some legislation that relaxed some
anti-trust legislation and provided for some other stuff ... that was to
promote commercial transfer of gov. technology ... with the objective of
improving US competitive position in the world. this shows up (at least)
in commercialization of various stuff from national labs ... including
various kinds of storage management; LANL ... datatree; LLNL
.... unitree, and NCAR (SAN mentioned in previous post) ... Mesa
We were actively involved in the unitree effort and also got asked to do
some stuff with the Mesa Archival effort by people at NCAR. Part of it
was the san jose disk division was investing/funding Mesa Archival
activity ... and we were asked to go by Mesa Archival to see how things
were going &/or provide help. This was somewhat to sidestep some of the
internal politics that happened with more direct activity.
http://www.garlic.com/~lynn/2009s.html#34 Larrabee delayed: anyone know what's happening?
After we left in '92 ... we did various consulting activities ... like
the stuff for small client/server startup that is now frequently called
"electronic commerce" ... and for Steve Chen when he was CTO at Sequent.
There was also guy at LLNL that was trying to "commercialize" various
LLNL technologies ... one was trying to move some LLNL chip technology
into commercial smartcard world. Part of that was using the anti-trust
relaxation for commercial consortium and the formation of FSTC
.... current FSTC (even tho there appears to be little current LLNL
even the LLNL FSTC webpage at wayback machine says the page
has moved and then redirects to above URL
misc. past posts mentioning Mesa Archival:
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2002q.html#23 Free Desktop Cyber emulation on PC before Christmas
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
http://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003i.html#53 A Dark Day
http://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005e.html#15 Device and channel
http://www.garlic.com/~lynn/2005e.html#16 Device and channel
http://www.garlic.com/~lynn/2005e.html#19 Device and channel
http://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006u.html#27 Why so little parallelism?
http://www.garlic.com/~lynn/2007j.html#47 IBM Unionization
http://www.garlic.com/~lynn/2008b.html#58 How does ATTACH pass address of ECB to child?
http://www.garlic.com/~lynn/2009k.html#58 Disksize history question
40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anton Ertl on 28 Dec 2009 10:37
Mayan Moudgill <mayan(a)bestweb.net> writes:
>Andy "Krazy" Glew wrote:
>> Yep. It's caching. Reuse of memory.
>> I've run experiments where you never reuse a memory location. (You can
>> do it even without language support, by a mapping in your simulator.)
>> Performance very bad. 2X-4X worse.
>> You have to somehow reuse memory to benefit from caches.
>Or use an architecture which supports
>allocate-and-0-line-without-fetching - PowerPC dcbz instruction.
Unfortunately, that's at best semi-architected, because the cache-line
size is not architected. And the proper sequence of cache control
instructions, sync etc. also seems to be implementation dependent as
well. In particular, when I searched for how to modify code on a
PowerPC, all the versions I found always had the caveat attached that
they work only on some machines.
A properly architected instruction in this vein is Alpha's WH64.
M. Anton Ertl Some things have to be seen to be believed
anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen
From: Mayan Moudgill on 28 Dec 2009 11:52
> Consider a program that has a large array of one-byte flags, and needs
> to update that array in parallel. No single flag will be accessed by
> two different threads without synchronisation, but the adjacency
> properties are such that it cannot practically be separated into one
> array for each thread. You can get the same issue by splitting up a
> very large string (think DNA or whatever).
This kind of computation will have performance issues on single threaded
code as well - for large enough array sizes, you'll get horrible cache
hit rates. Potentially *EVERY* update will cause a cache miss. In that
case, going multi-core *COULD* give you super-linear _speed-up_ due to
increased aggreate cache-size.
From: nmm1 on 28 Dec 2009 12:20
In article <7qSdna5HxYemf6XWnZ2dnUVZ_tudnZ2d(a)bestweb.net>,
Mayan Moudgill <mayan(a)bestweb.net> wrote:
> > Consider a program that has a large array of one-byte flags, and needs
> > to update that array in parallel. No single flag will be accessed by
> > two different threads without synchronisation, but the adjacency
> > properties are such that it cannot practically be separated into one
> > array for each thread. You can get the same issue by splitting up a
> > very large string (think DNA or whatever).
>This kind of computation will have performance issues on single threaded
>code as well - for large enough array sizes, you'll get horrible cache
>hit rates. Potentially *EVERY* update will cause a cache miss. In that
>case, going multi-core *COULD* give you super-linear _speed-up_ due to
>increased aggreate cache-size.
No, no, not at all. SOME such code has the properties you describe;
other code has quite good caching properties, but relies on a few
byte-separation accesses. It's the latter that are the killer. Not
merely are they currently legal (almost recommended) and efficient,
but tracking down a small number of 'aliasing' problems if often a
nightmare. MTBF times of hours, with no two successive failures
showing up in the same way :-(
If the failure were trapped by hardware, there wouldn't be a problem,
but all it does is to give wrong answers, non-repeatably.