Larrabee delayed: anyone know what's happening?
|
Prev: PEEEEEEP
Next: Texture units as a general function
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. Regards, Nick Maclaren.
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. re: 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 Archival. 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 activity) http://www.fstc.org/ even the LLNL FSTC webpage at wayback machine says the page has moved and then redirects to above URL http://web.archive.org/web/*/http://www.llnl.gov/fstc 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/2008p.html#51 Barbless 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. - anton -- 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 http://www.complang.tuwien.ac.at/anton/home.html
From: Mayan Moudgill on 28 Dec 2009 11:52 nmm1(a)cam.ac.uk 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.
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. Regards, Nick Maclaren. |