Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #6484 > unrolled thread
| Started by | Mark Thorson <nospam@sonic.net> |
|---|---|
| First post | 2012-04-10 19:31 -0800 |
| Last post | 2012-04-14 08:02 -0700 |
| Articles | 20 on this page of 133 — 28 participants |
Back to article view | Back to comp.arch
Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-10 19:31 -0800
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-11 01:29 -0500
Re: Indirect Bit sarr.blumson@alum.dartmouth.org - 2012-04-11 14:48 +0000
Re: Indirect Bit mac <acolvin@efunct.com> - 2012-04-12 14:43 +0000
Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:19 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:24 -0700
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-11 08:32 +0200
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-11 05:49 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:22 -0700
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 08:14 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:13 -0700
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 20:01 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-14 03:16 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 08:14 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:05 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:01 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 13:49 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-13 20:07 -0400
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-14 18:47 +0200
Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:26 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:25 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 09:18 +0100
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-23 19:35 -0400
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 08:37 +0100
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 09:42 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 01:58 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 11:26 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 05:02 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:58 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 10:07 -0700
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 04:30 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:01 +0100
Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-11 10:03 -0400
Re: Indirect Bit kenney@cix.compulink.co.uk - 2012-04-11 09:22 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:11 -0700
Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-12 18:05 -0400
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:13 -0700
Re: Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-12 16:55 -0800
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 17:25 -0700
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-12 20:03 -0500
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:33 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 15:57 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:03 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:14 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-11 10:35 -0400
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-11 08:54 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 07:55 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-12 10:16 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-12 11:07 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:34 -0700
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-12 11:35 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:41 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-13 14:52 -0700
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 09:24 -0700
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-15 22:45 +0200
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 18:04 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:12 -0700
Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-12 19:23 +0000
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-13 08:54 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-14 14:37 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-15 23:42 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:08 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:38 +0000
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:29 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:25 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:05 -0700
Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 10:12 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 06:25 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-14 14:50 +0100
Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 18:01 +0000
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 14:00 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-14 20:58 -0400
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 09:57 -0700
Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-20 23:19 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:50 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 18:09 +0100
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:19 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-17 09:20 +0100
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-17 12:49 +0200
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 12:40 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-18 12:01 +0100
Re: Indirect Bit anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-17 12:34 +0000
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-17 09:10 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 22:05 +0000
Re: Indirect Bit jgk@panix.com (Joe keane) - 2012-04-19 19:37 +0000
Re: Indirect Bit torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-20 11:10 +0200
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-20 11:24 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:01 +0100
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:03 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-20 08:01 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 16:35 +0100
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:10 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:37 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-16 11:21 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 19:36 +0100
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:17 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:33 -0700
Re: Indirect Bit Andreas Eder <andreas_eder@gmx.net> - 2012-04-19 00:29 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 10:50 +0100
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-19 11:29 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 21:39 +0100
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-20 15:14 -0400
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-20 22:43 -0700
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-21 17:14 -0400
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-21 19:47 -0500
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 10:45 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 09:57 +0100
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-22 12:54 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:00 +0100
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 13:28 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:04 +0100
Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-22 23:00 +0200
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-22 18:05 -0400
Re: Indirect Bit glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-22 23:20 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:22 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-22 03:56 -0700
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-22 12:28 -0400
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 12:56 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:15 -0700
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 22:30 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 21:40 +0100
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 17:15 -0500
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:26 +0100
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-23 08:02 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 17:02 +0100
Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-23 20:17 +0200
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-23 13:07 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:16 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-23 13:14 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-23 16:51 -0400
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-23 14:22 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-21 11:17 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-14 08:02 -0700
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-04-22 23:25 -0700 |
| Message-ID | <4F94F5EF.2030204@SPAM.comp-arch.net> |
| In reply to | #6601 |
On 4/22/2012 6:26 AM, Morten Reistad wrote: > In article<13f57392-9259-4e47-825f-fc031c9be857@v17g2000pbt.googlegroups.com>, > Quadibloc<jsavard@ecn.ab.ca> wrote: >> On Apr 12, 10:22 pm, "Andy (Super) Glew"<a...@SPAM.comp-arch.net> >> wrote: >> >>> Now, many of the supercomputer folks I used to work with think that >>> caches are a waste of power. I'm not there yet. >> >> We know from IBM's disappointing results with the STRETCH and the >> 360/91, and its unexpected bonus of performance from the 360/85, that >> caches not only work, but they work well. On most normal computational >> tasks, they make RAM look almost like it is as fast as the more >> expensive and more power-consuming memory used in the cache. >> >> So caches are anything but a waste in most computers. On the one hand, >> some supercomputers, though, are sometimes used for problems with poor >> locality. On the other hand, the 360/195, for example, got by very >> nicely with 32 Kbytes of cache, and so it might legitimately be asked >> if something like 2 Mbytes of cache as often found on current >> microprocessors is really needed. >> >> But performance results do show that the larger caches do pay off - >> and part of the problem is how current operating systems work; another >> part is shorter cycle times that make the cache miss penalty higher. > > Benchmarks show this clearly. Just having hyperchannel cache links > on of off can be the difference between 12k telephone calls and barely > 600. > > -- mrr > I should have been more clear: They think (thought?) that cache coherence was a waste of power. They are (were) divided on caches per se.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-23 09:18 +0100 |
| Message-ID | <jn337v$r62$1@needham.csi.cam.ac.uk> |
| In reply to | #6616 |
In article <4F94F5EF.2030204@SPAM.comp-arch.net>, Andy (Super) Glew <andy@SPAM.comp-arch.net> wrote: >On 4/22/2012 6:26 AM, Morten Reistad wrote: >> In article<13f57392-9259-4e47-825f-fc031c9be857@v17g2000pbt.googlegroups.com>, >> Quadibloc<jsavard@ecn.ab.ca> wrote: >>> On Apr 12, 10:22 pm, "Andy (Super) Glew"<a...@SPAM.comp-arch.net> >>> wrote: >>> >>>> Now, many of the supercomputer folks I used to work with think that >>>> caches are a waste of power. I'm not there yet. >> >I should have been more clear: They think (thought?) that cache >coherence was a waste of power. They are (were) divided on caches per se. Yes. And they (we) have most of the facts on our side :-( What isn't clear is whether cache coherence actually brings much benefit to ANY area - I know that Holy Dogma states that it is essential, but hard evidence is somewhat lacking. As far as parallelism is concerned, it doesn't help distributed memory (MPI) or virtual shared memory (PGAS) at all, and doesn't help OpenMP or similar shared-memory designs enough to get excited about; tightly-coupled designs (C++) are so far almost unused. The same applies to most of the other aspects of Unix-derived systems, whether process arguments, the file cache, loading, or shared-memory segments - it doesn't help. As far as correctness (whether kernel or user process, parallelism or interrupts) is concerned, it doesn't help significantly. This is because 'causal consistency' isn't enough without some explicit management and because a lot of the real problems occur with the non-memory actions (which always need special action, and are broken in POSIX). What is needed and used, but is not always available, is a clean, explicit, consistent memory (and other state!) model, with explicit, reasonably cheap instructions to ensure well-defined consistency states. The lack of that is a major reason that modern systems are so unreliable, with low-probability, unrepeatable misbehaviour. Now, if we had that, how much extra benefit would be gained from automatic coherence (and of which form) is a moot point. But, at present, it is largely used to reduce the probability of failure, thus preserving the bugs while making them almost unreportable, unfindable and unfixable. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-04-23 19:35 -0400 |
| Message-ID | <5Hllr.64357$R85.25309@newsfe17.iad> |
| In reply to | #6619 |
nmm1@cam.ac.uk wrote: > > Yes. And they (we) have most of the facts on our side :-( What > isn't clear is whether cache coherence actually brings much benefit > to ANY area - I know that Holy Dogma states that it is essential, > but hard evidence is somewhat lacking. I tripped over this but have only had a chance to give it a quick read due to chasing 'entanglement' developments. (There were some things I might take issue with but I want to reread first.) Why On-Chip Cache Coherence is Here to Stay (2012) Milo M. K. Martin, Mark D. Hill, Daniel J. Sorin http://www.cis.upenn.edu/acg/papers/cacm12_why_coherence_nearfinal.pdf Eric
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-24 08:37 +0100 |
| Message-ID | <jn5l8i$1b3$1@needham.csi.cam.ac.uk> |
| In reply to | #6630 |
In article <5Hllr.64357$R85.25309@newsfe17.iad>, EricP <ThatWouldBeTelling@thevillage.com> wrote: >> >> Yes. And they (we) have most of the facts on our side :-( What >> isn't clear is whether cache coherence actually brings much benefit >> to ANY area - I know that Holy Dogma states that it is essential, >> but hard evidence is somewhat lacking. > >I tripped over this but have only had a chance to give >it a quick read due to chasing 'entanglement' developments. >(There were some things I might take issue with >but I want to reread first.) > >Why On-Chip Cache Coherence is Here to Stay (2012) >Milo M. K. Martin, Mark D. Hill, Daniel J. Sorin >http://www.cis.upenn.edu/acg/papers/cacm12_why_coherence_nearfinal.pdf Thanks. It is certainly going to outlast me, but my point wasn't that it is going away or even that it is too expensive (on-chip). It was entirely that its claimed benefits are largely illusory. A quick glance at that paper indicates that the worst effect in their design is that the number of transactions could double in a workload that does a great deal of read-only cache loading. What I didn't see was an analysis of its effect on parallelism and memory consistency. E.g. can it still deliver sequential or even causal consistency if every core spins off multiple cache accesses, asynchronously. My crude analyses are that maintaining the invariant that a single location never goes backwards in time is easy, but that maintaining definable and usable coherence model (e.g. sequential consistency) is seriously antagonistic to scalability. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-24 09:42 +0100 |
| Message-ID | <jn5p2c$1gm$1@needham.csi.cam.ac.uk> |
| In reply to | #6633 |
In article <jn5l8i$1b3$1@needham.csi.cam.ac.uk>, <nmm1@cam.ac.uk> wrote: >In article <5Hllr.64357$R85.25309@newsfe17.iad>, >EricP <ThatWouldBeTelling@thevillage.com> wrote: >>> >>Why On-Chip Cache Coherence is Here to Stay (2012) >>Milo M. K. Martin, Mark D. Hill, Daniel J. Sorin >>http://www.cis.upenn.edu/acg/papers/cacm12_why_coherence_nearfinal.pdf After a slightly more thorough look, I found a couple of largely irrelevant errors. For example "To reduce recalls, the shared cache always chooses to evict non-shared blocks over shared blocks." Well, THAT's obviously not going to work! But a minor tweak would solve it. However, my main objection is that it made no reference to the global consistency model at all, and seemed to assume that implementing cache coherence is all that is needed. Well, that ain't so .... I still can't see how you can deliver (say) sequential consistency scalably, though I can't quite convince myself that it's impossible. I am 95% sure that it is, but can't make my analysis watertight. Curiously, I have the same view on IRIW, which IS delivered by Intel - but Intel currently don't make high core-count systems! Some of my colleagues are experts in this area, and they are also in two minds about this issue. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2012-04-24 01:58 -0700 |
| Message-ID | <f27fd04e-eaf2-411c-855b-10a8b2456543@9g2000yqp.googlegroups.com> |
| In reply to | #6635 |
On Apr 24, 11:42 am, n...@cam.ac.uk wrote: > I still can't see how you can deliver (say) sequential consistency > scalably, though I can't quite convince myself that it's impossible. > I am 95% sure that it is, but can't make my analysis watertight. > Curiously, I have the same view on IRIW, which IS delivered by > Intel - but Intel currently don't make high core-count systems! > Some of my colleagues are experts in this area, and they are also > in two minds about this issue. > > Regards, > Nick Maclaren. Define high core-count.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-24 11:26 +0100 |
| Message-ID | <jn5v59$2ao$1@needham.csi.cam.ac.uk> |
| In reply to | #6636 |
In article <f27fd04e-eaf2-411c-855b-10a8b2456543@9g2000yqp.googlegroups.com>, Michael S <already5chosen@yahoo.com> wrote: > >> I still can't see how you can deliver (say) sequential consistency >> scalably, though I can't quite convince myself that it's impossible. >> I am 95% sure that it is, but can't make my analysis watertight. >> Curiously, I have the same view on IRIW, which IS delivered by >> Intel - but Intel currently don't make high core-count systems! >> Some of my colleagues are experts in this area, and they are also >> in two minds about this issue. > >Define high core-count. 256+. All of the Intel-based systems use their own glue chips, as far as I know. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2012-04-24 05:02 -0700 |
| Message-ID | <8ecc4366-6d5a-4f84-ad3e-283f1134cc08@12g2000vba.googlegroups.com> |
| In reply to | #6637 |
On Apr 24, 1:26 pm, n...@cam.ac.uk wrote: > In article <f27fd04e-eaf2-411c-855b-10a8b2456...@9g2000yqp.googlegroups.com>, > Michael S <already5cho...@yahoo.com> wrote: > > > > >> I still can't see how you can deliver (say) sequential consistency > >> scalably, though I can't quite convince myself that it's impossible. > >> I am 95% sure that it is, but can't make my analysis watertight. > >> Curiously, I have the same view on IRIW, which IS delivered by > >> Intel - but Intel currently don't make high core-count systems! > >> Some of my colleagues are experts in this area, and they are also > >> in two minds about this issue. > > >Define high core-count. > > 256+. Well, I always regarded Sun Fire 15K/25K (106/144 cores) as high core count. But what I know? > All of the Intel-based systems use their own glue chips, > as far as I know. There are many glueless 8-socket/80-core Intel Xeon based systems. I think, with exception of HP and IBM, just about everybody is glueless, also I am not 100% certain about NEC/Unisys. As to HP and IBM, despite the glue they certainly adhere to the same Intel/AMD memory ordering model. As to SGI Altix-UV, wihich would be high core-count even by your ultra-conservative definition, did they ever said that their memory ordering model is weaker than Intel's official manuals or it's just your speculations? > > Regards, > Nick Maclaren. Glueless
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-24 13:58 +0100 |
| Message-ID | <jn6812$5t6$1@needham.csi.cam.ac.uk> |
| In reply to | #6641 |
In article <8ecc4366-6d5a-4f84-ad3e-283f1134cc08@12g2000vba.googlegroups.com>, Michael S <already5chosen@yahoo.com> wrote: >> >> >Define high core-count. >> >> 256+. > >Well, I always regarded Sun Fire 15K/25K (106/144 cores) as high core >count. But what I know? Well, you should start by noting that the boundary increases with time, because increases in chip area can be used to alleviate problems. That does not affect the scalability, but changes its scale. >> All of the Intel-based systems use their own glue chips, >> as far as I know. > >There are many glueless 8-socket/80-core Intel Xeon based systems. I >think, with exception of HP and IBM, just about everybody is glueless, >also I am not 100% certain about NEC/Unisys. As to HP and IBM, despite >the glue they certainly adhere to the same Intel/AMD memory ordering >model. I have never seen any hard data on how that 80-core aberration behaves, and have heard informed sources doubting its technical merits. I believe that all of the scalable systems use glue chips. And, while many people repeat that claim about the memory model of their systems, hard evidence is scant - including when I was managing a multi-million procurement and asked the vendors for it. Do you have any evidence that it is actually delivered? >As to SGI Altix-UV, wihich would be high core-count even by your >ultra-conservative definition, did they ever said that their memory >ordering model is weaker than Intel's official manuals or it's just >your speculations? You appear to know very little about that system. Despite the considerable improvement over the Origin, the cost of their memory management is approximately quadratic in the number of cores, and their memory model isn't what you think it is. I have not used one of them, but I did break the Origin, and the developers did confirm that they couldn't guarantee consistency under sufficiently stressful conditions. Subsequent discussions indicate that the Altix does a lot better, but has probably merely made the problems much less likely. I shall not respond further unless you have something technical to contribute. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2012-04-24 10:07 -0700 |
| Message-ID | <d414ee92-b6f3-4efe-98cc-cb7e3cf904fb@v22g2000yqm.googlegroups.com> |
| In reply to | #6643 |
On Apr 24, 3:58 pm, n...@cam.ac.uk wrote: > In article <8ecc4366-6d5a-4f84-ad3e-283f1134c...@12g2000vba.googlegroups.com>, > Michael S <already5cho...@yahoo.com> wrote: > > > > >> >Define high core-count. > > >> 256+. > > >Well, I always regarded Sun Fire 15K/25K (106/144 cores) as high core > >count. But what I know? > > Well, you should start by noting that the boundary increases with > time, because increases in chip area can be used to alleviate > problems. That does not affect the scalability, but changes its > scale. > > >> All of the Intel-based systems use their own glue chips, > >> as far as I know. > > >There are many glueless 8-socket/80-core Intel Xeon based systems. I > >think, with exception of HP and IBM, just about everybody is glueless, > >also I am not 100% certain about NEC/Unisys. As to HP and IBM, despite > >the glue they certainly adhere to the same Intel/AMD memory ordering > >model. > > I have never seen any hard data on how that 80-core aberration > behaves, and have heard informed sources doubting its technical > merits. I believe that all of the scalable systems use glue chips. There are SAP-SD 2-tier benchmarks indicating that performance difference between gluefull HP DL980 and glueless systems from Hitachi and Fujitsu is no more than 3-4%. IBM x3850 X5 is available both in glueless and in gluefull 80-core configurations. IBM itself never said that gluefull is faster. The main point of IBM glue is not speed, but increased memory capacity and ability to use cheaper Xeon models (E7-4800 instead of E7-8800). When it comes to absolute scalability, on SAP-SD 2-tier glueless 80- cores outperform 40-cores by factor of 1.8 which I'd consider pretty good scaling. As to embarrassingly parallel benchmarks: SpecJbb2005 - x1.83 (HP - x1.93) SpecInt2006_rate - x1.70 (HP - x1.93) SpecFp2006_rate - x1.58 (HP - x1.94) BTW, even ignoring SGI, current Intel 80-cores are not the biggest cc- NUMA machine that implement relatively strict memory ordering rules. This honors belong to 256-core Fujitsu/Oracle m9000. If I am not mistaken, their memory ordering at least as restrictive as x386/iAMD64 "sequential consistency minus local store-to-load forwarding minus unordered string instructions" model. > And, while many people repeat that claim about the memory model of > their systems, hard evidence is scant - including when I was managing > a multi-million procurement and asked the vendors for it. > > Do you have any evidence that it is actually delivered? > > >As to SGI Altix-UV, wihich would be high core-count even by your > >ultra-conservative definition, did they ever said that their memory > >ordering model is weaker than Intel's official manuals or it's just > >your speculations? > > You appear to know very little about that system. Despite the > considerable improvement over the Origin, the cost of their memory > management is approximately quadratic in the number of cores, I fully agree that when one attempts to use huge SGI machine as if it was regular small NUMA he can't expect satisfactory performance. But we are not talking about performance here, do we? > and their memory model isn't what you think it is. If their memory ordering model is not what specified in respective processor's architecture manuals (3 different processor architectures for 4 generations of SGI's big NUMA products) then I'd expect from very respectfull company like SGI to issue their own memory ordering model whitepapers. But I didn't see such whitepapers. Did you? > I have not used > one of them, but I did break the Origin, and the developers did > confirm that they couldn't guarantee consistency under sufficiently > stressful conditions. Subsequent discussions indicate that the > Altix does a lot better, but has probably merely made the problems > much less likely. > > I shall not respond further unless you have something technical > to contribute. > > Regards, > Nick Maclaren. Nick, even when you have something technical to contribute, which, I suppose, is quite often the case, you somehow manages to express it in way that is almost indistinguishable from handwaving. Just reread the following: " I have not used one of them, but I did break the Origin, and the developers did confirm that they couldn't guarantee consistency under sufficiently stressful conditions. Subsequent discussions indicate that the Altix does a lot better, but has probably merely made the problems much less likely." If it's not handwaving then it's pretty damn good imitation of handwaving.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2012-04-24 04:30 -0700 |
| Message-ID | <56f11ed4-de0c-49b3-a56d-0b67554d0fe5@v1g2000yqm.googlegroups.com> |
| In reply to | #6633 |
On Apr 24, 10:37 am, n...@cam.ac.uk wrote: > In article <5Hllr.64357$R85.25...@newsfe17.iad>, > > EricP <ThatWouldBeTell...@thevillage.com> wrote: > > >> Yes. And they (we) have most of the facts on our side :-( What > >> isn't clear is whether cache coherence actually brings much benefit > >> to ANY area - I know that Holy Dogma states that it is essential, > >> but hard evidence is somewhat lacking. > > >I tripped over this but have only had a chance to give > >it a quick read due to chasing 'entanglement' developments. > >(There were some things I might take issue with > >but I want to reread first.) > > >Why On-Chip Cache Coherence is Here to Stay (2012) > >Milo M. K. Martin, Mark D. Hill, Daniel J. Sorin > >http://www.cis.upenn.edu/acg/papers/cacm12_why_coherence_nearfinal.pdf > > Thanks. It is certainly going to outlast me, but my point wasn't > that it is going away or even that it is too expensive (on-chip). > It was entirely that its claimed benefits are largely illusory. > > A quick glance at that paper indicates that the worst effect in > their design is that the number of transactions could double in a > workload that does a great deal of read-only cache loading. What > I didn't see was an analysis of its effect on parallelism and > memory consistency. E.g. can it still deliver sequential or > even causal consistency if every core spins off multiple cache > accesses, asynchronously. > > My crude analyses are that maintaining the invariant that a single > location never goes backwards in time is easy, but that maintaining > definable and usable coherence model (e.g. sequential consistency) > is seriously antagonistic to scalability. > > Regards, > Nick Maclaren. My take on the issue is approximately like that: cache coherence done is hardware, is just a relatively efficient automatic implementation of generic optimization pattern known as leisure evaluation. I.e. cache coherence is a win as long as leisure evaluation strategy for cache line transfers is a win. Looking from that angle, usefulness of cache coherence hardware is almost independent of specific memory ordering model. After all, memory ordering model only influences the amount and variate of explicit memory barriers that are necessary for correctness. So, memory ordering model could influence the win/loss balance only for corner cases of very fine-grain parallelism.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-24 13:01 +0100 |
| Message-ID | <jn64mo$5o2$1@needham.csi.cam.ac.uk> |
| In reply to | #6639 |
In article <56f11ed4-de0c-49b3-a56d-0b67554d0fe5@v1g2000yqm.googlegroups.com>, Michael S <already5chosen@yahoo.com> wrote: >> >> My crude analyses are that maintaining the invariant that a single >> location never goes backwards in time is easy, but that maintaining >> definable and usable coherence model (e.g. sequential consistency) >> is seriously antagonistic to scalability. > >My take on the issue is approximately like that: >cache coherence done is hardware, is just a relatively efficient >automatic implementation of generic optimization pattern known as >leisure evaluation. I.e. cache coherence is a win as long as leisure >evaluation strategy for cache line transfers is a win. Assuming that you mean lazy evaluation, that's reasonable. >Looking from that angle, usefulness of cache coherence hardware is >almost independent of specific memory ordering model. After all, >memory ordering model only influences the amount and variate of >explicit memory barriers that are necessary for correctness. So, >memory ordering model could influence the win/loss balance only for >corner cases of very fine-grain parallelism. Your take has almost exactly the same flaw as that paper! The killer is asynchronicity, which is a key to parallel scalability. Lamport's original paper explained that serialising access at both the CPUs and memory servers is enough for sequential consistency but, if you have a LOT of them, that's precisely what you don't want to have to do! In particular, it makes a big difference if you can allow write buffering and prefetching; Intel allows the former. The big trouble with understanding this is that it inherently the global properties that cause the trouble, and so ANY serial analysis (e.g. in that paper) is misleading. And it is sufficiently hard that decades of work haven't produced any definitive answer to whether scalable sequential consistency is or is not possible. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2012-04-11 10:03 -0400 |
| Message-ID | <jwvlim29xlf.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #6484 |
> last pointer was found (indirect bit = 0). This allowed the
> CPU to run through linked lists without wasting instruction
> bandwidth and registers reading in the pointers so they can
> address memory.
Since indirections are typically slow/costly, the waste in instruction
bandwidth is only a problem if you're concerned about saving power: you
won't have much other work to do in the mean time anyway.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | kenney@cix.compulink.co.uk |
|---|---|
| Date | 2012-04-11 09:22 -0500 |
| Message-ID | <K_OdnQdP7IQQDhjSnZ2dnUVZ8tadnZ2d@giganews.com> |
| In reply to | #6484 |
In article <4F84FB1E.6CD1FC88@sonic.net>, nospam@sonic.net (Mark Thorson) wrote: > In the future, no von Neumann architecture > machine will ever need more than 52 address bits for a user > application. I That is a bold assumption, every time memory space has increased people have been saying that that space would never be fully used. One reason the PC was set up like it was, was that 640K of memory would never be fully utilised. When 32 bit addressing was introduced there were very few boards that could mount 1 Meg of memory let alone 4. Ken Young
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-04-12 14:11 -0700 |
| Message-ID | <72e7ba91-76b9-49ec-b5fc-1313976aae34@v17g2000pbt.googlegroups.com> |
| In reply to | #6493 |
On Apr 11, 8:22 am, ken...@cix.compulink.co.uk wrote: > every time memory space has increased people > have been saying that that space would never be fully used. True. But I have difficulty imagining the kind of memory technology that would allow the use of addresses larger than 128 bits. Unless it's some sort of quantum memory that can store trillions of bits in every single atom. 10^23 is about 2^76... and, thus, 80 bits or so is about the limit for macroscopic memory devices storing one bit per atom. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2012-04-12 18:05 -0400 |
| Message-ID | <jwv4nsoobgn.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #6508 |
>> every time memory space has increased people
>> have been saying that that space would never be fully used.
> True. But I have difficulty imagining the kind of memory technology
> that would allow the use of addresses larger than 128 bits.
Assuming Moore's law, we eat a constant number of addressing bits per
year, but that still means that the time between "generations" (from 16
to 32, to 64, to 128, ...) increases exponentially, so it's only normal
that we'd stay for a long while in 64bit and for even loner in 128bit.
If you add the fact that Moore's law may not hold that long, we may
never reach the end of 128bit addresses (or maybe even 64bit addresses
for that matter).
Stefan
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-04-12 20:13 -0700 |
| Message-ID | <4F8799F0.3020407@SPAM.comp-arch.net> |
| In reply to | #6509 |
On 4/12/2012 3:05 PM, Stefan Monnier wrote: >>> every time memory space has increased people >>> have been saying that that space would never be fully used. >> True. But I have difficulty imagining the kind of memory technology >> that would allow the use of addresses larger than 128 bits. > > Assuming Moore's law, we eat a constant number of addressing bits per > year, but that still means that the time between "generations" (from 16 > to 32, to 64, to 128, ...) increases exponentially, so it's only normal > that we'd stay for a long while in 64bit and for even loner in 128bit. > > If you add the fact that Moore's law may not hold that long, we may > never reach the end of 128bit addresses (or maybe even 64bit addresses > for that matter). > > > Stefan Some of my friends have already worked on 128 bit processors - address space, that is. Not at Intel. Not in academia. In industry, at major companies. Heck, Itanium had an 80 bit address space - what I call a "folded" address space. IMHO the big argument for which is sharing libraries, at different 64 bit addresses, but at the same address in the unfolded 80 bit virtual address space. I vaguely recall a Philips processor with 70 or 72 bit addresses, but can't find a reference. So it may just be a failure of my memory.
[toc] | [prev] | [next] | [standalone]
| From | Mark Thorson <nospam@sonic.net> |
|---|---|
| Date | 2012-04-12 16:55 -0800 |
| Message-ID | <4F87799B.F019D9DB@sonic.net> |
| In reply to | #6508 |
Quadibloc wrote: > > 10^23 is about 2^76... and, thus, 80 bits or so is about the limit for > macroscopic memory devices storing one bit per atom. The limit is a lot lower than that. Assume you have to write and read each location at least once. That provides an upper bound on how much memory a von Neumann machine can use. Even if you could make more memory, you wouldn't be able to use it.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-04-12 17:25 -0700 |
| Message-ID | <34f253f7-9ded-4356-b746-6ae423b3fdb4@h10g2000pbi.googlegroups.com> |
| In reply to | #6510 |
On Apr 12, 6:55 pm, Mark Thorson <nos...@sonic.net> wrote: > Assume you have to write and read > each location at least once. That > provides an upper bound on how much > memory a von Neumann machine can use. You haven't seen the quad-core machines turning up at your local computer store yet? That machines will continue to be von Neuman uniprocessor computers, rather than some sort of massively parallel architecture... is not a physical constraint, and, in fact, appears to be contra-indicated by current trends. So the fact that a machine with 2^80 bytes of RAM might also have 2^40 processors (or just 2^30 processors) in it... is not necessarily a fatal obstacle to the existence of such a machine. And address space doesn't have to be RAM. Remember VSAM? It could well be that the entire hard drive equivalent will be mapped into address space, and so "read and written at least once" would apply to the life of the machine, not to a given session between reboots. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-04-12 20:03 -0500 |
| Message-ID | <21ueo79ns6gcn64npjnau9g7ouhhsob24m@4ax.com> |
| In reply to | #6511 |
On Thu, 12 Apr 2012 17:25:25 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca> wrote: >On Apr 12, 6:55 pm, Mark Thorson <nos...@sonic.net> wrote: > >> Assume you have to write and read >> each location at least once. That >> provides an upper bound on how much >> memory a von Neumann machine can use. > >You haven't seen the quad-core machines turning up at your local >computer store yet? > >That machines will continue to be von Neuman uniprocessor computers, >rather than some sort of massively parallel architecture... is not a >physical constraint, and, in fact, appears to be contra-indicated by >current trends. > >So the fact that a machine with 2^80 bytes of RAM might also have 2^40 >processors (or just 2^30 processors) in it... is not necessarily a >fatal obstacle to the existence of such a machine. > >And address space doesn't have to be RAM. Remember VSAM? It could well >be that the entire hard drive equivalent will be mapped into address >space, and so "read and written at least once" would apply to the life >of the machine, not to a given session between reboots. You're probably thinking of the S/38 / AS/400's single-level-storage scheme, where all of the attached disk storage was basically accessed as a giant memory mapped file. VSAM, as in IBM mainframes, was (is) just an ISAM package, more-or-less replacing the older access method actually named "ISAM" (plus providing some other file formats). There's nothing really "virtual" about it, it just got named in the era when IBM was slapping the "virtual" label in front of everything, because that was hot. We seem a similar prefixing of "i" and "e" to everything in sight over the last decade. More on topic, accesses rates become an issue as devices get bigger - this is especially acute for disks - in the early 80s, you could read an entire 3380 disk in about five minutes (sequentially, of course). Modern 3TB disks take on the order of four hours, simply because you have to let the things spin ~1.5 million times to get to all the data. Assuming we keep using disks, current growth rates would increase that another factor of 50 in the next 30 years, which will pretty much make backing up a hard disk impossible (just a sequential read of a disk would take over a week).
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.arch
csiph-web