Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #4284 > unrolled thread
| Started by | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| First post | 2011-10-20 19:51 +0000 |
| Last post | 2011-10-26 14:12 -0700 |
| Articles | 20 on this page of 175 — 34 participants |
Back to article view | Back to comp.arch
big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-20 19:51 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-20 22:35 +0200
Re: big-little Mark Thorson <nospam@sonic.net> - 2011-10-20 14:18 -0800
Re: big-little nmm1@cam.ac.uk - 2011-10-21 07:54 +0100
Re: big-little David Kanter <dkanter@gmail.com> - 2011-11-09 01:06 -0800
Re: big-little nmm1@cam.ac.uk - 2011-11-09 11:07 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 09:25 +0200
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-21 11:07 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-21 16:28 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-21 17:07 +0100
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-21 13:25 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-21 19:45 +0000
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-22 14:44 -0400
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-22 16:57 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-22 17:40 +0100
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-23 14:39 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-23 16:11 +0100
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-23 17:44 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-23 18:46 +0100
Re: big-little Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-10-23 19:30 +0100
Re: big-little nmm1@cam.ac.uk - 2011-10-23 19:59 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-23 13:21 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-23 20:38 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-23 22:38 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-23 17:56 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-24 07:58 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-24 16:34 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-25 08:09 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-25 14:52 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-25 17:28 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-25 13:06 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-25 15:22 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-25 19:47 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 08:09 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-26 12:06 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-26 10:47 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-26 11:58 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-26 10:44 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 03:45 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 11:45 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 09:15 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 12:51 -0700
Re: big-little Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-26 11:45 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-26 15:42 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 09:07 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 12:53 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 21:05 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:20 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 17:55 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 09:10 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 01:34 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 10:29 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 04:28 -0700
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-27 12:22 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-27 18:08 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 11:50 -0700
Re: big-little Jean-Marc Bourguet <jm@bourguet.org> - 2011-10-27 14:10 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-27 17:58 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:15 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 04:10 -0700
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-27 14:04 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 23:07 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 15:58 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-27 22:57 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 16:39 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-28 00:16 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-28 09:52 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-28 07:01 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-28 16:45 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-29 13:13 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-30 03:36 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-30 03:55 -0700
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-28 11:15 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-28 20:01 +0100
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-29 17:46 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-29 11:30 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-29 20:02 +0100
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-29 13:09 -0700
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-29 17:42 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-30 08:16 +0000
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-11-04 10:06 -0700
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-11-04 15:19 -0700
Re: big-little nmm1@cam.ac.uk - 2011-11-05 09:13 +0000
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-11-05 09:03 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:38 -0700
Re: big-little Robert Wessel <robertwessel2@yahoo.com> - 2011-10-26 18:44 -0500
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 17:05 -0700
Re: big-little Robert Wessel <robertwessel2@yahoo.com> - 2011-10-26 21:03 -0500
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 14:37 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 15:38 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 16:06 -0400
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-27 00:15 -0700
Re: big-little Morten Reistad <first@last.name> - 2011-11-03 17:30 +0100
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-11-03 20:45 -0700
Re: big-little Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-11-04 11:13 +0000
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-11-04 10:12 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-04 09:26 -0700
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-11-05 11:32 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-11-05 11:55 -0400
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 09:58 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-05 18:39 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 15:00 -0700
Re: big-little wclodius@lost-alamos.pet (William Clodius) - 2011-11-05 18:43 -0600
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 19:46 -0700
Re: big-little ChrisQ <meru@devnull.com> - 2011-11-11 12:31 +0000
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 12:39 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-11 13:28 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 18:03 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-12 18:25 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-12 12:02 -0700
cost of prolog/epilog (was: big-little) Kalle Olavi Niemitalo <kon@iki.fi> - 2011-11-12 22:57 +0200
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-12 22:47 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-14 09:45 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-14 12:28 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-15 16:48 +0000
Re: cost of prolog/epilog Stefan Monnier <monnier@iro.umontreal.ca> - 2011-11-15 21:35 -0500
Re: cost of prolog/epilog Bakul Shah <usenet@bitblocks.com> - 2011-11-16 02:41 -0800
Re: cost of prolog/epilog nmm1@cam.ac.uk - 2011-11-16 18:14 +0000
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-16 16:50 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-14 17:00 -0700
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-15 10:26 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 09:41 -0700
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-15 16:40 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-15 12:44 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 09:01 -0700
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-15 15:18 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 21:56 -0700
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-16 09:21 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-16 09:30 +0000
Re: cost of prolog/epilog John Levine <johnl@iecc.com> - 2011-11-16 10:05 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-16 11:08 +0100
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-16 16:29 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-16 11:22 -0700
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-17 13:27 +0000
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-17 10:30 -0700
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-17 11:21 +0100
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-17 11:56 +0100
Re: cost of prolog/epilog timcaffrey@aol.com (Tim McCaffrey) - 2011-11-17 20:27 +0000
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-18 10:57 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-17 10:42 -0700
Re: cost of prolog/epilog (was: big-little) "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-11-12 14:05 -0800
Re: cost of prolog/epilog (was: big-little) Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-18 02:39 +0100
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-18 10:59 +0100
Re: cost of prolog/epilog Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-18 22:06 +0100
Re: cost of prolog/epilog (was: big-little) mac <acolvin@efunct.com> - 2011-11-20 23:01 +0000
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-13 13:35 -0700
Re: big-little wclodius@lost-alamos.pet (William Clodius) - 2011-11-11 22:13 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 23:43 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-12 14:08 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-12 19:10 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-13 13:40 -0700
Re: big-little Bakul Shah <usenet@bitblocks.com> - 2011-11-13 14:49 -0800
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-13 18:51 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-24 10:12 +0200
Re: big-little Stefan Monnier <monnier@iro.umontreal.ca> - 2011-10-24 12:11 -0400
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-24 10:28 -0700
Re: big-little nospam@ab-katrinedal.dk (Niels Jørgen Kruse) - 2011-10-24 19:38 +0200
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-24 21:02 +0200
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-23 12:02 -0700
Re: big-little Morten Reistad <first@last.name> - 2011-11-03 00:51 +0100
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-20 16:59 -0700
Re: big-little Anne & Lynn Wheeler <lynn@garlic.com> - 2011-10-20 21:13 -0400
Re: big-little nmm1@cam.ac.uk - 2011-10-21 08:01 +0100
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-21 05:39 -0700
Re: big-little torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-10-24 10:18 +0200
Re: big-little Pedro Pereira <ppereira@grupopie.com> - 2011-10-21 10:40 +0100
Re: big-little Paul Gotch <paulg@at-cantab-dot.net> - 2011-10-21 12:42 +0100
Re: big-little nik Simpson <nik_s@knology.net> - 2011-10-21 11:00 -0500
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-20 21:13 +0000
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-20 21:43 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 09:23 +0200
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 14:35 +0200
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-21 17:15 +0000
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-21 16:41 -0700
Re: big-little jacko <jackokring@gmail.com> - 2011-10-26 14:12 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2011-10-27 14:04 -0700 |
| Message-ID | <11644628.1655.1319749467802.JavaMail.geo-discussion-forums@yqhp35> |
| In reply to | #4435 |
On Thursday, October 27, 2011 6:10:39 AM UTC-5, Michael S wrote: > I tried to think a bit more about it. > May be, sequential consistency is not as hard to implement as I > initially imagined. > Current x86 multiprocessor implementations (with possible exception of > the new SGI Altix-UV) are pretty close to it already. Unofficially > they conform to a model that I'd call "N-2 sequential consistency" > described as: > "...for every arbitrary couple of processors in the system, the result > of any execution is the same as if the operations of all *other* the > processors were executed in some sequential order, and the operations > of each individual processor appear in this sequence in the order > specified by its program." Current x86 processors operate under "Causal Consistency". But when push comes to shove, it is NOT "that" expensive to take a Causally Consistent architecture and make it sequentially consistent (Where expensive is in terms of area, cycles, or time.) Mitch
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-27 23:07 +0100 |
| Message-ID | <j8ckne$2kl$1@gosset.csi.cam.ac.uk> |
| In reply to | #4449 |
In article <11644628.1655.1319749467802.JavaMail.geo-discussion-forums@yqhp35>, MitchAlsup <comp.arch@googlegroups.com> wrote: > >Current x86 processors operate under "Causal Consistency". > >But when push comes to shove, it is NOT "that" expensive to take a >Causally Consistent architecture and make it sequentially consistent >(Where expensive is in terms of area, cycles, or time.) I am unconvinced that even the current Intel specification will be viable once the number of cores gets to 64 or so. The main guarantee that it gives that I find bizarre is IRIW (Independent Reads of Independent Writes), but I know that I am thinking in terms of distributed memory and message passing. However, as core counts go up, shared memory is simply going to have to move towards that approach. I know that the Altix does somewhat better, but 64 cores was where the cost of the consistency logic started to overtake the cost of the CPUs and memory logic on the Origin. And, even then, it didn't get exception handling entirely right. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-27 15:58 -0700 |
| Message-ID | <c60af814-a265-49d0-91c1-bba826d18f23@h5g2000vbf.googlegroups.com> |
| In reply to | #4450 |
n...@cam.ac.uk wrote: > In article <11644628.1655.1319749467802.JavaMail.geo-discussion-forums@yqhp35>, > MitchAlsup <comp.arch@googlegroups.com> wrote: > > > >Current x86 processors operate under "Causal Consistency". > > > >But when push comes to shove, it is NOT "that" expensive to take a > >Causally Consistent architecture and make it sequentially consistent > >(Where expensive is in terms of area, cycles, or time.) > > I am unconvinced that even the current Intel specification will > be viable once the number of cores gets to 64 or so. Since last April 80-core x86 system (8 sockets, 160 execution threads) became sort of expensive commodity. The performance scaling on benchmarks like SAP-SD 2-tier and Specjbb2008 from 10 to 20 to 40 cores is actually very good, and from 40 to 80 cores rather not bad (factor 1.8 in SAP-SD 2-tier, factor 1.9 in Specjbb2008). 8MB true inclusive last-level cache shared by all 10 cores of each socket helps a lot. > The main > guarantee that it gives that I find bizarre is IRIW (Independent > Reads of Independent Writes), but I know that I am thinking in > terms of distributed memory and message passing. However, as > core counts go up, shared memory is simply going to have to move > towards that approach. > According to my understanding, the term IRIW is not very popular outside of Cambridge. Am I correct? It sounds good but hardly describes anything. Of course the same could be said about Total Store Ordering, Processor Consistency, Sequential Consistency etc. Memory ordering model (any model, not just that of x86) is simply too complex matter to be adequately expressed in 2, 3 or 4 words. As to bizzare part, as you, of course, know, x86 memory model was not carefully planned. It grew like Topsy. Such process often results in decent working solution that is not very easy to explain.
[toc] | [prev] | [next] | [standalone]
| From | Rick Jones <rick.jones2@hp.com> |
|---|---|
| Date | 2011-10-27 22:57 +0000 |
| Message-ID | <j8cnl6$441$1@usenet01.boi.hp.com> |
| In reply to | #4452 |
Michael S <already5chosen@yahoo.com> wrote: > Since last April 80-core x86 system (8 sockets, 160 execution threads) > became sort of expensive commodity. > The performance scaling on benchmarks like SAP-SD 2-tier and > Specjbb2008 from 10 to 20 to 40 cores is actually very good, and > from 40 to 80 cores rather not bad (factor 1.8 in SAP-SD 2-tier, > factor 1.9 in Specjbb2008). Do you mean SPECjbb2005? rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-27 16:39 -0700 |
| Message-ID | <d9cf5965-39be-4af9-b011-d114e56db9ac@a17g2000yqj.googlegroups.com> |
| In reply to | #4454 |
On Oct 28, 12:57 am, Rick Jones <rick.jon...@hp.com> wrote: > Michael S <already5cho...@yahoo.com> wrote: > > Since last April 80-core x86 system (8 sockets, 160 execution threads) > > became sort of expensive commodity. > > The performance scaling on benchmarks like SAP-SD 2-tier and > > Specjbb2008 from 10 to 20 to 40 cores is actually very good, and > > from 40 to 80 cores rather not bad (factor 1.8 in SAP-SD 2-tier, > > factor 1.9 in Specjbb2008). > > Do you mean SPECjbb2005? > Yes, thanks. Still had SpecPower_ssj2008 from another discussion hanging in my mind.
[toc] | [prev] | [next] | [standalone]
| From | Rick Jones <rick.jones2@hp.com> |
|---|---|
| Date | 2011-10-28 00:16 +0000 |
| Message-ID | <j8cs8e$5vk$2@usenet01.boi.hp.com> |
| In reply to | #4455 |
Michael S <already5chosen@yahoo.com> wrote: > On Oct 28, 12:57 am, Rick Jones <rick.jon...@hp.com> wrote: > > Do you mean SPECjbb2005? > Yes, thanks. > Still had SpecPower_ssj2008 from another discussion hanging in my > mind. <pedantmode>SPECpower_ssj2008</pedantmode> :) Does it matter for the sake of this discussion that most folks run SPECjbb2005 with one JVM per socket, and there is no inter-JVM sharing of data? Nor going into the kernel for that matter. (Actually the same applies to SPECpower_ssj2008, and a couple other SPEC benchmarks :) rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-28 09:52 +0100 |
| Message-ID | <j8dqgm$7l8$1@gosset.csi.cam.ac.uk> |
| In reply to | #4452 |
In article <c60af814-a265-49d0-91c1-bba826d18f23@h5g2000vbf.googlegroups.com>, Michael S <already5chosen@yahoo.com> wrote: >n...@cam.ac.uk wrote: >> In article <11644628.1655.1319749467802.JavaMail.geo-discussion-forums@yqhp35>, >> MitchAlsup <comp.arch@googlegroups.com> wrote: >> > >> >Current x86 processors operate under "Causal Consistency". >> > >> >But when push comes to shove, it is NOT "that" expensive to take a >> >Causally Consistent architecture and make it sequentially consistent >> >(Where expensive is in terms of area, cycles, or time.) >> >> I am unconvinced that even the current Intel specification will >> be viable once the number of cores gets to 64 or so. > >Since last April 80-core x86 system (8 sockets, 160 execution threads) >became sort of expensive commodity. This is getting ridiculous. Yes, I know about those, and about Knight's Corner, and about the SGI Origin and Altix. And why those benchmarks are largely irrelevant in this context. And I remember how many developments and products have been released, only to disappear in the medium term. My point stands. >According to my understanding, the term IRIW is not very popular >outside of Cambridge. Am I correct? No. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-28 07:01 -0700 |
| Message-ID | <4ab5d31f-f166-4ae0-a710-0fcef41f687b@o5g2000yqa.googlegroups.com> |
| In reply to | #4460 |
On Oct 28, 10:52 am, n...@cam.ac.uk wrote: > In article <c60af814-a265-49d0-91c1-bba826d18...@h5g2000vbf.googlegroups.com>, > Michael S <already5cho...@yahoo.com> wrote: > > >n...@cam.ac.uk wrote: > >> In article <11644628.1655.1319749467802.JavaMail.geo-discussion-forums@yqhp35>, > >> MitchAlsup <comp.arch@googlegroups.com> wrote: > > >> >Current x86 processors operate under "Causal Consistency". > > >> >But when push comes to shove, it is NOT "that" expensive to take a > >> >Causally Consistent architecture and make it sequentially consistent > >> >(Where expensive is in terms of area, cycles, or time.) > > >> I am unconvinced that even the current Intel specification will > >> be viable once the number of cores gets to 64 or so. > > >Since last April 80-core x86 system (8 sockets, 160 execution threads) > >became sort of expensive commodity. > > This is getting ridiculous. Yes, I know about those, and about > Knight's Corner, and about the SGI Origin and Altix. Knights Corner and SGI Altix UV are specialized HPC setups. Strictly speaking they don't even have to conform to the memory ordering rules presented in Intel's official architecture books. Although Altix UV is probably still conforming. 8-socket 80-core Westmere-EX machines produced by HP, IBM, Dell, Fujitsu, HItachi, NEC, Unisys, Oracle etc are another story. They have to conform to every letter of Intel manuals. > And why those benchmarks are largely irrelevant in this context. So I probably lost the context. You said, in future tens "I am unconvinced that even the current Intel specification will be viable once the number of cores gets to 64 or so". I pointed out that since April 80(>64)core systems conforming to current Intel specification became moderately popular. Low volume 96-core systems from NEC/Unisys existed since 2008, but they did *not* demonstrate good performance scaling on embarrassingly parallel workloads with little or now communication between the cores, so one can interpret it as "specification was not viable" although I am personally convinced that the problem was in implementation rather than specification. So what is the context and why SAS SD 2-tier and SPEC_JBB2005 are irrelevant? Too little communication between the cores? True, esp for SPEC_JBB. But, IMHO, that makes the benchmark more relevant rather than less relevant. The situation with high percentage of cache misses, but little communication between the cores is exactly the situation in which broadcast-based implementation of cache coherence [that is used by these new bunch of 80-core machines, and that relatively easily maps into Intel specification for memory ordering] is at biggest disadvantage relatively to other cache coherence implementations, in particular distributed directories[that, supposedly not so easy to map into Intel specification]. > And I > remember how many developments and products have been released, > only to disappear in the medium term. My point stands. > This time relatively big volumes are involved. And many players. Yes, less than 0.5% of x86 servers market by volume, may be not even 0.1%, but we are still talking about [many?] 1000s of relative expensive boxes. Another development that is going on now is AMD Interlagos, which is already in OEMs hand for a couple of months. With Interlagos 64 cores are just 4 sockets, i.e. not an expensive commodity, but commodity without qualification. > Regards, > Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Rick Jones <rick.jones2@hp.com> |
|---|---|
| Date | 2011-10-28 16:45 +0000 |
| Message-ID | <j8em7t$vht$1@usenet01.boi.hp.com> |
| In reply to | #4464 |
Michael S <already5chosen@yahoo.com> wrote: > So what is the context and why SAS SD 2-tier and SPEC_JBB2005 are > irrelevant? > Too little communication between the cores? True, esp for SPEC_JBB. > But, IMHO, that makes the benchmark more relevant rather than less > relevant. The situation with high percentage of cache misses, but > little communication between the cores is exactly the situation in > which broadcast-based implementation of cache coherence [that is > used by these new bunch of 80-core machines, and that relatively > easily maps into Intel specification for memory ordering] is at > biggest disadvantage relatively to other cache coherence > implementations, in particular distributed directories[that, > supposedly not so easy to map into Intel specification]. I cannot speak to the rest of the 8 socket Intel systems, but the HP DL980 G7 employs XNCs (glue) and so may not be "end-to-end" broadcast cache coherence? (I get rapidly out of my depth in hardware, mostly wanted to make sure it was clear they weren't all just 8 socket glueless systems) I believe that IBM were going to offer similar glue, then were not, and then were again, so perhaps they are too, perhaps they are not. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-29 13:13 -0700 |
| Message-ID | <0b87115f-aca4-43de-9cec-f2ba017881b5@q16g2000yqn.googlegroups.com> |
| In reply to | #4472 |
On Oct 28, 6:45 pm, Rick Jones <rick.jon...@hp.com> wrote: > Michael S <already5cho...@yahoo.com> wrote: > > So what is the context and why SAS SD 2-tier and SPEC_JBB2005 are > > irrelevant? > > Too little communication between the cores? True, esp for SPEC_JBB. > > But, IMHO, that makes the benchmark more relevant rather than less > > relevant. The situation with high percentage of cache misses, but > > little communication between the cores is exactly the situation in > > which broadcast-based implementation of cache coherence [that is > > used by these new bunch of 80-core machines, and that relatively > > easily maps into Intel specification for memory ordering] is at > > biggest disadvantage relatively to other cache coherence > > implementations, in particular distributed directories[that, > > supposedly not so easy to map into Intel specification]. > > I cannot speak to the rest of the 8 socket Intel systems, but the HP > DL980 G7 employs XNCs (glue) and so may not be "end-to-end" broadcast > cache coherence? (I get rapidly out of my depth in hardware, mostly > wanted to make sure it was clear they weren't all just 8 socket > glueless systems) I believe that IBM were going to offer similar glue, > then were not, and then were again, so perhaps they are too, perhaps > they are not. > > rick jones > -- > The glass is neither half-empty nor half-full. The glass has a leak. > The real question is "Can it be patched?" > these opinions are mine, all mine; HP might not want them anyway... :) > feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... I think, Dell, Fujitsu and Sun/Oracle are glueless. Don't have a slightest idea about Hitachi, NEC and Unisys. IBM MAX5 chip is not really similar to HP XNC. It is also capable of reducing snoop latency, but in different conditions. That is, XNC reduces latency when requested cache line *is not* cached in remote nodes and belongs to local memory. IBM MAX5 reduces the latency when cache line *is* cached in remote nodes. So, theoretically, HP 8-socket systems should be faster for workloads with little or no data sharing between the sockets, while IBM's system should be faster for workloads with significant inter-socket data sharing. Also, according to my understanding, MAX5 can not be considered a glue in 8-socket configuration, because it does not set between any two Xeons, but more like hangs on the side. However I am not 100% sure about said above, because IBM did not provide the interconnect scheme for "2-node x3850 X5 with MAX5" configuration, although such configuration is certainly supported and even necessary if you want to reach max. memory capacity of 3 TB. For those interested: http://www.redbooks.ibm.com/redpapers/pdfs/redp4650.pdf http://h30423.www3.hp.com/redirect.jsp?r=1&url=http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA3-0643ENW.pdf
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-30 03:36 -0700 |
| Message-ID | <75ef35f5-a02b-43a1-8472-eb3ea7347ca9@a12g2000vbz.googlegroups.com> |
| In reply to | #4512 |
On Oct 29, 10:13 pm, Michael S <already5cho...@yahoo.com> wrote: > On Oct 28, 6:45 pm, Rick Jones <rick.jon...@hp.com> wrote: > > > > > Michael S <already5cho...@yahoo.com> wrote: > > > So what is the context and why SAS SD 2-tier and SPEC_JBB2005 are > > > irrelevant? > > > Too little communication between the cores? True, esp for SPEC_JBB. > > > But, IMHO, that makes the benchmark more relevant rather than less > > > relevant. The situation with high percentage of cache misses, but > > > little communication between the cores is exactly the situation in > > > which broadcast-based implementation of cache coherence [that is > > > used by these new bunch of 80-core machines, and that relatively > > > easily maps into Intel specification for memory ordering] is at > > > biggest disadvantage relatively to other cache coherence > > > implementations, in particular distributed directories[that, > > > supposedly not so easy to map into Intel specification]. > > > I cannot speak to the rest of the 8 socket Intel systems, but the HP > > DL980 G7 employs XNCs (glue) and so may not be "end-to-end" broadcast > > cache coherence? (I get rapidly out of my depth in hardware, mostly > > wanted to make sure it was clear they weren't all just 8 socket > > glueless systems) I believe that IBM were going to offer similar glue, > > then were not, and then were again, so perhaps they are too, perhaps > > they are not. > > > rick jones > > -- > > The glass is neither half-empty nor half-full. The glass has a leak. > > The real question is "Can it be patched?" > > these opinions are mine, all mine; HP might not want them anyway... :) > > feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... > > I think, Dell, Fujitsu and Sun/Oracle are glueless. Don't have a > slightest idea about Hitachi, NEC and Unisys. > > IBM MAX5 chip is not really similar to HP XNC. > It is also capable of reducing snoop latency, but in different > conditions. > That is, XNC reduces latency when requested cache line *is not* cached > in remote nodes and belongs to local memory. IBM MAX5 reduces the > latency when cache line *is* cached in remote nodes. > So, theoretically, HP 8-socket systems should be faster for workloads > with little or no data sharing between the sockets, while IBM's system > should be faster for workloads with significant inter-socket data > sharing. > > Also, according to my understanding, MAX5 can not be considered a glue > in 8-socket configuration, because it does not set between any two > Xeons, but more like hangs on the side. > However I am not 100% sure about said above, because IBM did not > provide the interconnect scheme for "2-node x3850 X5 with MAX5" > configuration, although such configuration is certainly supported and > even necessary if you want to reach max. memory capacity of 3 TB. > > For those interested:http://www.redbooks.ibm.com/redpapers/pdfs/redp4650.pdfhttp://h30423.www3.hp.com/redirect.jsp?r=1&url=http://h20195.www2.hp.... So I decided to look at available benchmarks to try to see effects of HP XNC and IBM MAX5 SpecFp2006_rate (heavily bandwidth limited, no data sharing, 80cores/ 40 cores): HP - 1430/absent Glueless (Fujitsu) - 1190/751 IBM - absent/741 SpecInt2006_rate_base (moderately bandwidth limited, no data sharing, 80cores/40 cores): HP - 2070/absent Glueless (HITACHI/Fujitsu) - 1790/1030 IBM - 1770/741 SpecJbb2008 (moderately bandwidth limited, no data sharing between sockets, some sharing within socket, 80cores/40 cores): HP - 5307339/absent Glueless (Fujitsu) - 4966457/2708886 IBM - absent/2582363, with different JVM SAP-SD 2-tier (lightly bandwidth limited, non-trivial sharing between sockets, 80cores/40 cores): IBM - 25500/14000, with different database software HP - 25160/13550 Glueless (Fujitsu) - 24000/13285 TPC-E (lightly bandwidth limited, significant sharing between sockets, 80cores/40 cores): IBM - 4,593.17/2,862.61 Glueless (Fujitsu) - 4,555.54/absent HP - absent/2,454.51 Unlike other benchmarks listed above, in TCP-E processors/memory is not the only factor, just the biggest one. So, it looks like XNC glue helps HP to distance themselves from competition in irrelevant (for this class of machines) 8-way benchmarks like SpecInt_rate and especially SpecFp_rate. In the single relevant 8-way benchmark they did win over "commodity", but did not quite match IBM. I'd guess, HP can do better in other somewhat relevant field - server consolidation. However, server consolidation is only "somewhat" relevant for 8-way machines. Generally, most consolidation goes into smaller 2 and 4-way machines.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-30 03:55 -0700 |
| Message-ID | <69558522-1c6e-4558-a229-3af5e611bf6a@4g2000yqu.googlegroups.com> |
| In reply to | #4527 |
On Oct 30, 12:36 pm, Michael S <already5cho...@yahoo.com> wrote: > On Oct 29, 10:13 pm, Michael S <already5cho...@yahoo.com> wrote: > > > SpecInt2006_rate_base (moderately bandwidth limited, no data sharing, > 80cores/40 cores): > HP - 2070/absent > Glueless (HITACHI/Fujitsu) - 1790/1030 > IBM - 1770/741 > My mistake here. The correct scores are: SpecInt2006_rate_base (moderately bandwidth limited, no data sharing, 80cores/40 cores): HP - 2070/absent Glueless (HITACHI/Fujitsu) - 1790/1030 IBM - 1770/1000
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2011-10-28 11:15 -0700 |
| Message-ID | <22374797.1522.1319825720498.JavaMail.geo-discussion-forums@yqp37> |
| In reply to | #4450 |
On Thursday, October 27, 2011 5:07:42 PM UTC-5, nm...@cam.ac.uk wrote: > In article <11644628.1655.1319749467802.JavaMail.geo-discussion-forums@yqhp35>, > MitchAlsup <comp...@googlegroups.com> wrote: > > > >Current x86 processors operate under "Causal Consistency". > > > >But when push comes to shove, it is NOT "that" expensive to take a > >Causally Consistent architecture and make it sequentially consistent > >(Where expensive is in terms of area, cycles, or time.) > > I am unconvinced that even the current Intel specification will > be viable once the number of cores gets to 64 or so. If you recall a post of mine about 5 years ago; I stated that there will not be a way to feed a 64-core/thread due to memory bandwidths (pin counts) constraints; even after sacrificing the fabric interconnect pins for more DRAM pins. > The main > guarantee that it gives that I find bizarre is IRIW (Independent > Reads of Independent Writes), but I know that I am thinking in > terms of distributed memory and message passing. However, as > core counts go up, shared memory is simply going to have to move > towards that approach. As long as snooping* reaches "every interested" Core making a Causualy Consistent memory system "appear" to be SC to every interested core is not that hard. Making it appear to be SC to an absolutely incoherent I/O system is where it gets difficult. (*) This provides for snoop based and directory based approaches to work. Mitch
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-28 20:01 +0100 |
| Message-ID | <j8eu6n$e95$1@gosset.csi.cam.ac.uk> |
| In reply to | #4476 |
In article <22374797.1522.1319825720498.JavaMail.geo-discussion-forums@yqp37>, MitchAlsup <comp.arch@googlegroups.com> wrote: >> > >> >But when push comes to shove, it is NOT "that" expensive to take a >> >Causally Consistent architecture and make it sequentially consistent >> >(Where expensive is in terms of area, cycles, or time.) >> >> I am unconvinced that even the current Intel specification will >> be viable once the number of cores gets to 64 or so. > >If you recall a post of mine about 5 years ago; I stated that there will >not be a way to feed a 64-core/thread due to memory bandwidths (pin >counts) constraints; even after sacrificing the fabric interconnect pins >for more DRAM pins. Yup. And, given your assumptions, I am not disagreeing. However, you may remember a post of mine where I described how it can be done (which I did NOT invent). All that has to be done is to reduce the power requirements enough that the DRAM and CPU can be sandwiched together (which would allow a massive increase in the number of 'pins'), and then all of the existing pins could be used for I/O and power. I am not holding my breath :-) >As long as snooping* reaches "every interested" Core making a Causualy >Consistent memory system "appear" to be SC to every interested core is >not that hard. Making it appear to be SC to an absolutely incoherent >I/O system is where it gets difficult. (*) This provides for snoop >based and directory based approaches to work. Well, the first problem is that either the amount of snoop traffic goes up quadratically with the number of cores, or the amount of logic does (or some combination). And a second is that the latency is a serious problem, because of RC delay, and even the speed of light limits the performance. I have not seen any serious results on the performance under heavy communication load of the latest high core count systems, or any analysis of the consequence of maintaining Intel's model. I assume the latter exists, but is internal. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2011-10-29 17:46 +0000 |
| Message-ID | <j8he5u$hev$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #4478 |
In article <j8eu6n$e95$1@gosset.csi.cam.ac.uk>, nmm1@cam.ac.uk says... > >In article <22374797.1522.1319825720498.JavaMail.geo-discussion-forums@yqp37>, >MitchAlsup <comp.arch@googlegroups.com> wrote: >>> > >>> >But when push comes to shove, it is NOT "that" expensive to take a >>> >Causally Consistent architecture and make it sequentially consistent >>> >(Where expensive is in terms of area, cycles, or time.) >>> >>> I am unconvinced that even the current Intel specification will >>> be viable once the number of cores gets to 64 or so. >> >>If you recall a post of mine about 5 years ago; I stated that there will >>not be a way to feed a 64-core/thread due to memory bandwidths (pin >>counts) constraints; even after sacrificing the fabric interconnect pins >>for more DRAM pins. > >Yup. And, given your assumptions, I am not disagreeing. However, >you may remember a post of mine where I described how it can be done >(which I did NOT invent). All that has to be done is to reduce >the power requirements enough that the DRAM and CPU can be >sandwiched together (which would allow a massive increase in the >number of 'pins'), and then all of the existing pins could be >used for I/O and power. I am not holding my breath :-) > Given recent announcements by Intel&Micron it looks like this is Intel's next step. Perhaps with the way the power curve is decreasing Intel thinks this will be possible in a couple of years. Perhaps a future version of Atom. This may lead to the interesting situation that for certain workloads the cellphone may be faster than the desktop (similar to what happened when desktop/workstations starting being faster than mainframes). Time for another paradigm shift... - Tim
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-29 11:30 -0700 |
| Message-ID | <f8c3575a-a7da-43f2-b3c5-ac8737181db6@f27g2000yqn.googlegroups.com> |
| In reply to | #4478 |
On Oct 28, 9:01 pm, n...@cam.ac.uk wrote: > In article <22374797.1522.1319825720498.JavaMail.geo-discussion-forums@yqp37>, > > MitchAlsup <comp.arch@googlegroups.com> wrote: > > >> >But when push comes to shove, it is NOT "that" expensive to take a > >> >Causally Consistent architecture and make it sequentially consistent > >> >(Where expensive is in terms of area, cycles, or time.) > > >> I am unconvinced that even the current Intel specification will > >> be viable once the number of cores gets to 64 or so. > > >If you recall a post of mine about 5 years ago; I stated that there will > >not be a way to feed a 64-core/thread due to memory bandwidths (pin > >counts) constraints; even after sacrificing the fabric interconnect pins > >for more DRAM pins. > > Yup. And, given your assumptions, I am not disagreeing. > > Regards, > Nick Maclaren. May be, I misunderstood your original post NIck. When you said 64 cores, did you mean "64 cores per coherence domain" or "64 cores per socket"? If the later I certainly agree. More so, like Mitch, I think that they will hit the wall much earlier, between 20 and 32 "fat" cores. "Lean' cores is another story, but I don't think that, away from HPC, huge number of general-purpose "lean" cores is a good idea. If the former, I also agree in principle, that there exists a threshold and that we are not far away. But I think that there threshold is somewhere in 200 to 500 cores range. Now, factually, SGI is already shipping Altix UV systems 2560 x86 cores in a single coherence domain, but I am not sure that their system adhere to Intel definition. Would like to see a comment from somebody with better knowledge of Altix UV.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-29 20:02 +0100 |
| Message-ID | <j8hij8$mvi$1@gosset.csi.cam.ac.uk> |
| In reply to | #4507 |
In article <f8c3575a-a7da-43f2-b3c5-ac8737181db6@f27g2000yqn.googlegroups.com>, Michael S <already5chosen@yahoo.com> wrote: > >May be, I misunderstood your original post NIck. >When you said 64 cores, did you mean "64 cores per coherence domain" >or "64 cores per socket"? Either per socket, or per domain for a desktop system. It's moot, as I doubt that we shall see more than dual socket desktops in the near future, and not even that in the commodity market. >Now, factually, SGI is already shipping Altix UV systems 2560 x86 >cores in a single coherence domain, but I am not sure that their >system adhere to Intel definition. >Would like to see a comment from somebody with better knowledge of >Altix UV. The SGI Origin maintained sequential consistency, and went up to 2048 cores. That is a strict superset of Intel's model. I am not certain (it's too long ago now), but I believe that the Altix is the same. I can witness that it failed in the presence of a nasty enough exception load, but I have been told by people who know more than I do about Intel systems that the same is almost certainly true for those vis-a-vis Intel's model. But, as I posted, at that scale, the majority of the cost of the CPU and memory system goes in maintaining that coherence. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2011-10-29 13:09 -0700 |
| Message-ID | <12858059.253.1319918966244.JavaMail.geo-discussion-forums@yqiu15> |
| In reply to | #4478 |
On Friday, October 28, 2011 2:01:43 PM UTC-5, nm...@cam.ac.uk wrote: > In article <22374797.1522.1319825720498.JavaMail.geo-discussion-forums@yqp37>, > MitchAlsup <comp...@googlegroups.com> wrote: > >As long as snooping* reaches "every interested" Core making a Causualy > >Consistent memory system "appear" to be SC to every interested core is > >not that hard. Making it appear to be SC to an absolutely incoherent > >I/O system is where it gets difficult. (*) This provides for snoop > >based and directory based approaches to work. > > Well, the first problem is that either the amount of snoop traffic > goes up quadratically with the number of cores, or the amount of > logic does (or some combination). And a second is that the latency > is a serious problem, because of RC delay, and even the speed of > light limits the performance. Enter the snoop filter: A section of some large multi-way cache is sacrificed to contain snoop information and this storage is allocated to the memory controller. Say 1 way from a 8MB 16-way cache. One can maintain enough state over several million pages to know whether to broadcast a snoop (or not) based on whether that page has been read or written. It is sort of a directory of pages one knows enough about to avoid broadcasting snoops and under certain conditions sending directed snoops (bothers 1 out of 2**n nodes). I know at least one 4-node 6-core/node system that would have been snoop bound on the fabric interconnect if this filter was not removing 80%-ish of the snoop traffic. The loss in snoop traffic saves more cycles in a large MP system than the loss of 1/16th of the large outermost on-die cache. > I have not seen any serious results on the performance under heavy > communication load of the latest high core count systems, or any > analysis of the consequence of maintaining Intel's model. I assume > the latter exists, but is internal. They would not have implemented the filter if the snoop traffic proble was not raising its ugly head. Mitch
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-10-29 17:42 -0700 |
| Message-ID | <4f171b4f-b7ae-4b9a-93fa-01343a88ab7b@er6g2000vbb.googlegroups.com> |
| In reply to | #4513 |
On Oct 29, 3:09 pm, MitchAlsup <MitchAl...@aol.com> wrote: [snip] > I know at least one 4-node 6-core/node system that would > have been snoop bound on the fabric interconnect if this > filter was not removing 80%-ish of the snoop traffic. The > loss in snoop traffic saves more cycles in a large MP > system than the loss of 1/16th of the large outermost > on-die cache. And presumably the case becomes even stronger with compute density still following Moore's Law (and energy per computation not decreasing as rapidly) while off-chip bandwidth and power input/heat outflow per unit area remaining static. The computation/caching versus communication trade-offs seem to be getting continually more imbalanced (until we achieve quantum computation-- instant computation but it takes forever to enter the parameters and to communicate the result ;-).
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-30 08:16 +0000 |
| Message-ID | <j8j140$q9e$1@gosset.csi.cam.ac.uk> |
| In reply to | #4513 |
In article <12858059.253.1319918966244.JavaMail.geo-discussion-forums@yqiu15>, MitchAlsup <comp.arch@googlegroups.com> wrote: >> >> Well, the first problem is that either the amount of snoop traffic >> goes up quadratically with the number of cores, or the amount of >> logic does (or some combination). And a second is that the latency >> is a serious problem, because of RC delay, and even the speed of >> light limits the performance. > >Enter the snoop filter: A section of some large multi-way cache is >sacrificed to contain snoop information and this storage is allocated to >the memory controller. Say 1 way from a 8MB 16-way cache. ... I know almost nothing about the details of snoop filters, but my remarks applied both to basic snoop systems and to directories, and I should be flabberghasted if snoop filters weren't in some sense an intermediate form. I.e. they may well help, or even help a lot, but they will be subject to the same basic limitations of scalability, perhaps with a different constant. Do you know of a paper that describes the principles of snoop filters in enough mathematical detail to do realistic scalability calculations? >I know at least one 4-node 6-core/node system that would have been >snoop bound on the fabric interconnect if this filter was not removing >80%-ish of the snoop traffic. The loss in snoop traffic saves more >cycles in a large MP system than the loss of 1/16th of the large >outermost on-die cache. > >They would not have implemented the filter if the snoop traffic problem >was not raising its ugly head. Yes. 5 years ago, it was definitely the case that 4 socket glueless Intel systems and 8 socket AMDs were complete disasters; one colleague found that the aggregate bandwidth on 4 and 8 socket AMDs were the same, and I heard worse about 4 socket Intel. My guess is that recent improvements have alleviated that, a bit. And, as you know, the problem about shrinking large directory-based designs onto a single chip is that you need an extra generation of process just to cater for all the extra logic and wiring! It's that sort of thing that makes me doubt large-scale, sequentially or Intel causally consistent chips, even if the bandwidth could be resolved. And, as you know, that's not needed, because explicitly synchronised memory is good enough for almost all purposes. I am expecting a GPU-like design. For example, a 64-way chip might be 8 sequentially consistent domains, each of 8 cores, with explicit synchronisation between domains. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.arch
csiph-web