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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2011-11-04 10:06 -0700 |
| Message-ID | <11596169.387.1320426416698.JavaMail.geo-discussion-forums@yqce21> |
| In reply to | #4524 |
On Sunday, October 30, 2011 3:16:00 AM UTC-5, nm...@cam.ac.uk wrote: > In article <12858059.253.1319918966244.JavaMail.geo-discussion-forums@yqiu15>, > MitchAlsup <comp...@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. Think of the snoop filter like this: You get a swath of memory to keep track of things (groups of lines). The things you end up keeping track of don't need to get snooped (for example, you KNOW that the line is not in any processor cache) but for a few cases (You know that the line is in a cache on a node, but not whether is has been written or not. That is whether it made the transition from exclusive to modified). The things you did not keep track of need snooped as normal. (No info means revert back to snoop based cache coherence). The real question is how do you compress the directory so that it fits into the swath of memory you might have available. > Do you know of a paper that describes the principles of snoop filters > in enough mathematical detail to do realistic scalability calculations? Sorry, no. <snip> > 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. Couple of points: A) the snoop filter remembers which NODE contains the cache line, but not which processor. THis means that as the core count increases the directory pretty much stays the same. B) as the core count increases, the on-die largest cache increases in size--giving more room for the snoop filtering tables. C) Feeding large core count processors a standard amount of memory bandwidth is going to get the medium node systems (4-8) about the same time all the snoop filtering tricks run out of steam. D) one COULD put the directory in DRAM by using a more robust ECC which contains a compressed version of the directory--in the same number of bit as are currently used by data+ECC. Mitch
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-11-04 15:19 -0700 |
| Message-ID | <0d9d7af7-ffe4-41f1-82a4-ed0a85531885@h5g2000vbf.googlegroups.com> |
| In reply to | #4627 |
On Nov 4, 12:06 pm, MitchAlsup <MitchAl...@aol.com> wrote: [snip] > The real question is how do you compress the directory > so that it fits into the swath of memory you might > have available. Would there be any benefit in using a Bloom filter were a majority hit (e.g., 2 out of 3 indexes confirming a hit) indicated a local (for some definition of local where restricted snooping would provide a substantial benefit, e.g., a MCM) cached presence while a full hit indicated a remote cached presence? While such would have a higher false positive rate for locally cached detection than a full Bloom filter, such snoops would be less expensive and the use fewer set bits in that case might reduce the total false positive rate enough to compensate. [snip] > Couple of points: > A) the snoop filter remembers which NODE contains > the cache line, but not which processor. THis > means that as the core count increases the > directory pretty much stays the same. This is very much an implementation detail. The definition of 'node' could be L1 cache, (shared) L2 cache, chip, MCM, or even some larger unit. It seems that even on-chip bandwidth may be sufficiently limited that some filtering could be desirable. > B) as the core count increases, the on-die largest > cache increases in size--giving more room for the > snoop filtering tables. This might also decrease the relative size/power penalty for increasingly sophisticated logic to implement the filter. > C) Feeding large core count processors a standard > amount of memory bandwidth is going to get the > medium node systems (4-8) about the same time all > the snoop filtering tricks run out of steam. Interesting. Do you think special tricks like non-/software-coherent memory and library coherence (where a cache block is 'checked out' for a limited time) might buy a little time? > D) one COULD put the directory in DRAM by using a > more robust ECC which contains a compressed version > of the directory--in the same number of bit as are > currently used by data+ECC. One could also compress the data portion to extend the amount of information available to the directory data. If there are a large number of sharers, one could even simply use ECC bit stealing to indicate that the data is only available from one of the caches, so the entire data block would be available for directory information (as you had suggested here sometime). A partially dirty cache block could be "compressed" into just indicating which parts are dirty and where the dirty parts are cached, but that does not seem especially useful. The cost of such a directory seems a bit excessive in bandwidth use (reading an entire cache block when only the directory information is needed [even in the shared case, it can be cheaper to direct a sharer to send the data than to read and transmit the data from memory, though such could add excessive complication and waste of cache space by requiring the sharer to maintain the content of a victim block until the directory has been updated--though one might, with even greater complexity, allow a time-based dropping so that an explicit ACK would not need to be sent, unnecessarily consuming bandwidth]). The extra storage cost is probably not significant, especially given the restrictions of commodity memory chips. (It might be interesting to have the directory distributed with the memory, exploiting the potential extra bandwidth available on the command/address channel. If the memory chips are busy, the command could be buffered and the directory look-up could proceed and possibly cancel the memory transfer [transferring only one or two beats of data instead of the more typical 8], avoiding some unnecessary activity.) Since the Alpha 21364-based systems used such ECC bit stealing, this is likely to be a very reasonable approach, especially if one cannot afford adding complexity on top of complexity. (The Alpha directory might also have been less expensive because of the relatively great memory bandwidth.)
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-11-05 09:13 +0000 |
| Message-ID | <j92un7$kdh$1@gosset.csi.cam.ac.uk> |
| In reply to | #4635 |
In article <0d9d7af7-ffe4-41f1-82a4-ed0a85531885@h5g2000vbf.googlegroups.com>, Paul A. Clayton <paaronclayton@gmail.com> wrote: >On Nov 4, 12:06=A0pm, MitchAlsup <MitchAl...@aol.com> wrote: >[snip] >> The real question is how do you compress the directory >> so that it fits into the swath of memory you might >> have available. > >Would there be any benefit in using a Bloom filter >were a majority hit (e.g., 2 out of 3 indexes >confirming a hit) indicated a local (for some >definition of local where restricted snooping >would provide a substantial benefit, e.g., a MCM) >cached presence while a full hit indicated a >remote cached presence? ... Quite possibly, though I am not sure that exactly what you propose is viable. My point (which started this) was not that it could not be done crudely or cleverly, but that ALL such techniques have fairly fundamental limitations, and need a quadratic increase in resources to provide a linear benefit (in terms of the number of cores/cpus/sockets/boards/boxes/racks being handled). The other aspect is that, as with caching and TLBs, they all rely on the access pattern of the workload becoming more separable as the number of whatsits increases. That isn't a problem with Web servers and suchlike, which can even be implemented efficiently with SHMEM-like sharing, but IS a problem when you start to use parallelism to speed up logically serial applications. Bluntly, I think that continuing with the current 'plan' of using hardware to cover up the defects of software design has reached the end of the road. And, if you are going to tackle the software misdesign problem, why not abandon the extremely problematic large-scale cache-coherent memory consistency model? After all, GPUs have :-) Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-11-05 09:03 -0700 |
| Message-ID | <4EB55E40.70309@SPAM.comp-arch.net> |
| In reply to | #4639 |
On 11/5/2011 2:13 AM, nmm1@cam.ac.uk wrote: > In article<0d9d7af7-ffe4-41f1-82a4-ed0a85531885@h5g2000vbf.googlegroups.com>, > Paul A. Clayton<paaronclayton@gmail.com> wrote: >> On Nov 4, 12:06=A0pm, MitchAlsup<MitchAl...@aol.com> wrote: >> > Bluntly, I think that continuing with the current 'plan' of using > hardware to cover up the defects of software design has reached the > end of the road. And, if you are going to tackle the software > misdesign problem, why not abandon the extremely problematic > large-scale cache-coherent memory consistency model? After all, > GPUs have :-) Although AMD/ATI and ARM (with its Mali Midgard) have indicated a trend the other way.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-26 13:38 -0700 |
| Message-ID | <db5711c8-9f1a-43a0-b4c7-a262810f4e6a@s7g2000yqa.googlegroups.com> |
| In reply to | #4408 |
On Oct 26, 9:53 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> wrote: > On 10/26/2011 9:07 AM, Michael S wrote: > > > On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: > > >> Er, try a Web search for "sequential consistency" and look at the > >> first hit. > > > Nice definition, but absolutely impractical as main memory sequencing > > model. It looks impossible to implement in efficient manner on CMP/SMP > > with distributed caches and/or on any sorts of NUMA, even the > > cacheless ones. > > Interesting. > > It's the memory model for IBM mainframes. I googled around alittle and found this 1993 article by Sarita V. Adve: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.5143&rep=rep1&type=pdf She wrotes: "The IBM 370 memory model [IBM83] can be viewed as a combination of a restricted total store ordering and the weak ordering models, although it was defined before either. Like the other models in this section, the 370 guarantees that operations of a single processor will appear to execute in program order except for a write followed by a read to a different location. Additionally, the 370 also seems to guarantee that writes will appear to execute atomically; thus, a read cannot return a value from its processor’s write buffer until the write has been performed. The 370 also provides serialization instructions similar to the MB instruction of Alpha. Before executing a serialization operation, a processor completes all operations that precede the serialization operation. Before executing any nonserialization operation, a processor completes all serialization operations that precede that non-serialization operation. Some of the serialization instructions also access memory; therefore, memory operations from such instructions are equivalent to synchronization operations of weak ordering." This does not make sense to me. If local write forwarding is not allowed then what's the point of memory barrier?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-10-26 18:44 -0500 |
| Message-ID | <nc6ha7lseul8e97p84migvoelrq1m2n070@4ax.com> |
| In reply to | #4414 |
On Wed, 26 Oct 2011 13:38:39 -0700 (PDT), Michael S <already5chosen@yahoo.com> wrote: >On Oct 26, 9:53 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> >wrote: >> On 10/26/2011 9:07 AM, Michael S wrote: >> >> > On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: >> >> >> Er, try a Web search for "sequential consistency" and look at the >> >> first hit. >> >> > Nice definition, but absolutely impractical as main memory sequencing >> > model. It looks impossible to implement in efficient manner on CMP/SMP >> > with distributed caches and/or on any sorts of NUMA, even the >> > cacheless ones. >> >> Interesting. >> >> It's the memory model for IBM mainframes. > >I googled around alittle and found this 1993 article by Sarita V. >Adve: >http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.5143&rep=rep1&type=pdf >She wrotes: >"The IBM 370 memory model [IBM83] can be viewed as a combination of a >restricted total store ordering >and the weak ordering models, although it was defined before either. >Like the other models in this section, the >370 guarantees that operations of a single processor will appear to >execute in program order except for a write followed by a read to a >different location. Additionally, the 370 also seems to guarantee that >writes will appear to >execute atomically; thus, a read cannot return a value from its >processor’s write buffer until the write has been >performed. The 370 also provides serialization instructions similar to >the MB instruction of Alpha. Before executing >a serialization operation, a processor completes all operations that >precede the serialization operation. >Before executing any nonserialization operation, a processor completes >all serialization operations that precede >that non-serialization operation. Some of the serialization >instructions also access memory; therefore, memory >operations from such instructions are equivalent to synchronization >operations of weak ordering." > >This does not make sense to me. If local write forwarding is not >allowed then what's the point of memory barrier? While the results will appear in memory (as observed by other CPUs and channels) in the correct sequence, they're not necessarily there *yet*. Thus another CPU might be seeing changes a way back in the sequence until you issue the serializing (memory barrier) instruction.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-26 17:05 -0700 |
| Message-ID | <4a5d5b78-422d-42ba-a697-5917bc4a4bf1@y36g2000yqm.googlegroups.com> |
| In reply to | #4421 |
On Oct 27, 1:44 am, Robert Wessel <robertwess...@yahoo.com> wrote: > On Wed, 26 Oct 2011 13:38:39 -0700 (PDT), Michael S > > <already5cho...@yahoo.com> wrote: > >On Oct 26, 9:53 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> > >wrote: > >> On 10/26/2011 9:07 AM, Michael S wrote: > > >> > On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: > > >> >> Er, try a Web search for "sequential consistency" and look at the > >> >> first hit. > > >> > Nice definition, but absolutely impractical as main memory sequencing > >> > model. It looks impossible to implement in efficient manner on CMP/SMP > >> > with distributed caches and/or on any sorts of NUMA, even the > >> > cacheless ones. > > >> Interesting. > > >> It's the memory model for IBM mainframes. > > >I googled around alittle and found this 1993 article by Sarita V. > >Adve: > >http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.5143&rep=... > >She wrotes: > >"The IBM 370 memory model [IBM83] can be viewed as a combination of a restricted total store ordering > >and the weak ordering models, although it was defined before either. Like the other models in this section, the > >370 guarantees that operations of a single processor will appear to execute in program order except for a write followed by a read to a > >different location. Additionally, the 370 also seems to guarantee that writes will appear to > >execute atomically; thus, a read cannot return a value from its processor’s write buffer until the write has been > >performed. The 370 also provides serialization instructions similar to the MB instruction of Alpha. Before executing > >a serialization operation, a processor completes all operations that precede the serialization operation. > >Before executing any nonserialization operation, a processor completes all serialization operations that precede > >that non-serialization operation. Some of the serialization instructions also access memory; therefore, memory > >operations from such instructions are equivalent to synchronization operations of weak ordering." > > >This does not make sense to me. If local write forwarding is not allowed then what's the point of memory barrier? > > While the results will appear in memory (as observed by other CPUs and > channels) in the correct sequence, they're not necessarily there > *yet*. Thus another CPU might be seeing changes a way back in the > sequence until you issue the serializing (memory barrier) instruction. Now I'm even more lost. In order to "see" i.e. read the value the other CPU has to get the cache line. But if the value is modified cache line is now owned by our first CPU, right? And the other CPU can't see anything until modified line is either flushed to memory and reread from memory or transfered directly from the first CPU to the other CPU, right? That's the whole point of coherent caching in models like Total Store Ordering and Processor Consistency to both of which IBM mainframe supposed to conform, right? Or am I missing something really big there? Is IBM mainframe memory ordering model both as weak as Alpha and stronger than SPARC, all in the same time ?!
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-10-26 21:03 -0500 |
| Message-ID | <96eha7l7el9i2ptahaorbe2pj8ubhng5v0@4ax.com> |
| In reply to | #4422 |
On Wed, 26 Oct 2011 17:05:57 -0700 (PDT), Michael S
<already5chosen@yahoo.com> wrote:
>On Oct 27, 1:44 am, Robert Wessel <robertwess...@yahoo.com> wrote:
>> On Wed, 26 Oct 2011 13:38:39 -0700 (PDT), Michael S
>>
>> <already5cho...@yahoo.com> wrote:
>> >On Oct 26, 9:53 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
>> >wrote:
>> >> On 10/26/2011 9:07 AM, Michael S wrote:
>>
>> >> > On Oct 26, 4:42 pm, n...@cam.ac.uk wrote:
>>
>> >> >> Er, try a Web search for "sequential consistency" and look at the
>> >> >> first hit.
>>
>> >> > Nice definition, but absolutely impractical as main memory sequencing
>> >> > model. It looks impossible to implement in efficient manner on CMP/SMP
>> >> > with distributed caches and/or on any sorts of NUMA, even the
>> >> > cacheless ones.
>>
>> >> Interesting.
>>
>> >> It's the memory model for IBM mainframes.
>>
>> >I googled around alittle and found this 1993 article by Sarita V.
>> >Adve:
>> >http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.5143&rep=...
>> >She wrotes:
>> >"The IBM 370 memory model [IBM83] can be viewed as a combination of a restricted total store ordering
>> >and the weak ordering models, although it was defined before either. Like the other models in this section, the
>> >370 guarantees that operations of a single processor will appear to execute in program order except for a write followed by a read to a
>> >different location. Additionally, the 370 also seems to guarantee that writes will appear to
>> >execute atomically; thus, a read cannot return a value from its processor’s write buffer until the write has been
>> >performed. The 370 also provides serialization instructions similar to the MB instruction of Alpha. Before executing
>> >a serialization operation, a processor completes all operations that precede the serialization operation.
>> >Before executing any nonserialization operation, a processor completes all serialization operations that precede
>> >that non-serialization operation. Some of the serialization instructions also access memory; therefore, memory
>> >operations from such instructions are equivalent to synchronization operations of weak ordering."
>>
>> >This does not make sense to me. If local write forwarding is not allowed then what's the point of memory barrier?
>>
>> While the results will appear in memory (as observed by other CPUs and
>> channels) in the correct sequence, they're not necessarily there
>> *yet*. Thus another CPU might be seeing changes a way back in the
>> sequence until you issue the serializing (memory barrier) instruction.
>
>Now I'm even more lost.
>In order to "see" i.e. read the value the other CPU has to get the
>cache line. But if the value is modified cache line is now owned by
>our first CPU, right? And the other CPU can't see anything until
>modified line is either flushed to memory and reread from memory or
>transfered directly from the first CPU to the other CPU, right? That's
>the whole point of coherent caching in models like Total Store
>Ordering and Processor Consistency to both of which IBM mainframe
>supposed to conform, right?
>Or am I missing something really big there?
>Is IBM mainframe memory ordering model both as weak as Alpha and
>stronger than SPARC, all in the same time ?!
Well, it's something of a hybrid. It's much stronger than Alpha, in
that very little can actually happen out of order, but weak in the
manner of Alpha in that "normal" instructions don't have a deadline to
commit stores to globally visible memory.
But the point is that stores don't have to make it to the (coherent)
cache until a serialization event (memory barrier) occurs. It *does*
have to appear to have gotten to memory from the point of view of the
local processor (the one doing the store), but it can be pending in a
write buffer, for example, as far as other CPUs and channels in the
system are concerned.
The IBM z/Architecture Principles of Operation covers this in fair
detail:
http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf
Specifically, Chapter 5 ("Program Execution"), the "Sequence of
Storage References" and "Serialization" sections. Roughly pages 5-85
through 5-102).
This is largely unchanged (although expanded) since at least the early
S/370 multiprocessor days. And the need for serialization (memory
barriers) for I/O channel's access to memory dates back to the very
first S/360s.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-26 14:37 -0400 |
| Message-ID | <ysYpq.4037$Us1.3049@newsfe16.iad> |
| In reply to | #4393 |
nmm1@cam.ac.uk wrote:
>
> Yes, but that's not enough! Dekker's algorithm and others can fail
> even if that is true. Consider this example:
>
> Thread 1 Thread 2
> Synchronise
> A = 1 B = 1
> Print B Print A
>
> On Intel and AMD systems, you can and do have both print statements
> print zero. The writes are atomic but not sequentially consistent.
> See Litmus in:
>
> http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html
>
>
>
> Regards,
> Nick Maclaren.
Maybe someone can tell me if I am wrong in the following:
I'm reading one of the papers referenced on that page:
The Semantics of x86-CC Multiprocessor Machine Code
http://www.cl.cam.ac.uk/~pes20/weakmemory/popl09.pdf
which says the following in appendix A:
<quote>
Consider the following example, due to Paul Loewenstein.
n6 proc:0 proc:1
poi:0 MOV [100]<-$1 MOV [200]<-$2
poi:1 MOV EAX<-[100] MOV [100]<-$2
poi:2 MOV EBX<-[200]
Forbidden: 0:EAX=1 ^ 0:EBX=0 ^ [100]=1
The final state is:
- disallowed by our x86-CC formal model;
- disallowed by any reasonable interpretation, as far as
we can tell, of the current Intel and AMD published
specifications; but
- according to our preliminary test results, allowed by
at least one Intel processor (we find approximately one
witness in 2 ∗ 106 executions, reproducibly, on an Intel
Core 2, with our litmus tool).
<end quote>
(I'm guessing the above ^ symbol means 'and')
I believe the authors are wrong because x86 allows
intra-processor store to load forwarding.
1) proc:0 can forward $1 value to MOV EAX<-[100] before
the MOV [100]<-$1 hits the retire unit and commits,
and that allows MOV EBX<-[200] to load without bypassing
the prior load.
2) proc:1 then executes MOV [200]<-$2 and MOV [100]<-$2
3) proc:0 then retires MOV EAX<-[100] which overwrites [100] with 1
so we get 0:EAX=1 and 0:EBX=0 and [100]=1
Eric
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-26 15:38 -0400 |
| Message-ID | <mlZpq.400$tM2.51@newsfe15.iad> |
| In reply to | #4405 |
EricP wrote:
>
>
> 3) proc:0 then retires MOV EAX<-[100] which overwrites [100] with 1
^^^^
oops, I mean retires MOV [100]<-$1
>
> so we get 0:EAX=1 and 0:EBX=0 and [100]=1
>
> Eric
>
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-26 16:06 -0400 |
| Message-ID | <CLZpq.955$rF5.376@newsfe19.iad> |
| In reply to | #4405 |
EricP wrote: > > I believe the authors are wrong because x86 allows > intra-processor store to load forwarding. > > 1) proc:0 can forward $1 value to MOV EAX<-[100] before > the MOV [100]<-$1 hits the retire unit and commits, > and that allows MOV EBX<-[200] to load without bypassing > the prior load. > > 2) proc:1 then executes MOV [200]<-$2 and MOV [100]<-$2 > > 3) proc:0 then retires MOV [100]<-$1 which overwrites [100] with 1 > > so we get 0:EAX=1 and 0:EBX=0 and [100]=1 If the cache invalidate message for proc:1 MOV [200]<-$2 triggers a squash and replay for the proc:0 MOV EBX<-[200] then this premature load would not become visible. But it looks to me that the Intel rule 'Loads can bypass earlier stores to a different location' allows them to avoid this hardware. Eric
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-10-27 00:15 -0700 |
| Message-ID | <j8b0fu$arq$1@news.albasani.net> |
| In reply to | #4393 |
On 10/26/2011 2:44 AM, nmm1@cam.ac.uk wrote: > In article<072ln8-su1.ln1@ntp6.tmsw.no>, > Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: >> Andy "Krazy" Glew wrote: >> >>>>> Yes...and in some ways that would even be true...as long as you never >>>>> had an object larger than a single memory word... >>>>> :-) >>>> >>>> Sorry, Terje, not even then! You may be assuming sequential >>>> consistency, but that is not guaranteed by mere atomicity. >>> >>> Terminology check: many software people, especially Microsoft people my >>> experience, say "atomic" when they mean "sequential consistency". >>> >>> Their reasoning is "The operation appears to occur once and only once, >>> everywhere in the system, at the same time. If that isn;t atomic, what is?" >>> >> Except for the "at the same time" part, this is exactly what I meant: >> >> Every process observing/using/updating any item will either get the >> previous value, or the updated value, and never something that's >> half-way updated. > > Yes, but that's not enough! Dekker's algorithm and others can fail > even if that is true. Consider this example: > > Thread 1 Thread 2 > Synchronise > A = 1 B = 1 > Print B Print A > > On Intel and AMD systems, you can and do have both print statements > print zero. The writes are atomic but not sequentially consistent. > See Litmus in: > > http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html > IMHO, this depends on assumptions which are inherently unsafe in the general case. this is why there is often special language semantics, and/or special compiler intrinsics (such as "InterlockedExchange" and friends), to deal with these sorts of cases. the natural cost though is that, depending on architecture, these sorts of atomic/synchronized/... operations could become particularly expensive (vs operations using a more lax synchronization model). hence, generally cheaper is to not assume strict synchronization (unless otherwise insured by the language and/or implementation).
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name> |
|---|---|
| Date | 2011-11-03 17:30 +0100 |
| Message-ID | <3r2dnXmsb44LVi_TnZ2dnUVZ87-dnZ2d@telenor.com> |
| In reply to | #4369 |
In article <j84sm2$g94$1@news.albasani.net>, BGB <cr88192@hotmail.com> wrote: >On 10/23/2011 11:58 PM, nmm1@cam.ac.uk wrote: >> In article<j82d3u$6lt$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote: >>>>> >I don't think mismatched clock rates will break either the operation of >mutexes, of critical sections in general, or of things like message queues. We already have mismatched clock rates. The current crop of processors change speed all the time. Just go look with "Powertop" or some other utility. If we set up a hypervisor and some pretty simple virtualisation we can do a simple task switch, and let the single, low-speed cpu be master cpu as we finish, and then shut down the other cpus, mapping them to the single processor. Inverse action when usage comes back. If there is consistent, full usage the spindown never happens. >this is largely about like going and complaining that "rdtsc" is broken >because it will give different values and jump forwards/backwards, ... >as a thread gets rescheduled from one core to another, or because if one >calls rdtsc in a loop, there is some level of "noise" in the returned >values (presumably due to whatever else is going on in the system). > > >or such... We are already there. We may even be a lot better off by replacing the 133-633 Mhz speeds of the current high-end processors with a single core 600Mhz system; or possibly with multiple register sets for hyperthreading so it can better impoersonate all the other processors. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-11-03 20:45 -0700 |
| Message-ID | <4EB35FE9.1060000@SPAM.comp-arch.net> |
| In reply to | #4612 |
On 11/3/2011 9:30 AM, Morten Reistad wrote: > In article<j84sm2$g94$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote: >> On 10/23/2011 11:58 PM, nmm1@cam.ac.uk wrote: >>> In article<j82d3u$6lt$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote: >>>>>> > >> I don't think mismatched clock rates will break either the operation of >> mutexes, of critical sections in general, or of things like message queues. > > We already have mismatched clock rates. The current crop of processors > change speed all the time. Just go look with "Powertop" or some other > utility. AFAIK all of the current generation of multicore chips have all or most of the processors running at the same basic clock frequency at all times. I.e. they are all in the same frequency (and voltage) planes. (I should qualify: symmetric multicore. Not ARM big.LITTLE, Nvidia's 4+1, or the various SOCs with different cores.) I believe that one of the earliest AMD multicore chips allowed the OS to set each of the processors to a different frequency. But I believe they backed away from it, as everyone else seems to have. Why? I do not know. I conjecture that the overhead of truly asynchronous clocks, or even clocks of the same frequency but in no guaranteed phase relationship, was too high. But I also know that software providers complained a lot about the possibility of differing clock rates. Heck, they wanted all of the CPUs to be guaranteed to be of the same stepping, back when it was common to have different CU chips. It is possible that they allow the processors to run at different clock rates by adjusting clock dividers, or p/q rational ratios. However, most of the examples of stuff like Turbo mode shows all of the clock frequencies the same. I must admit that I wonder if this is true for some of the bigger 12 and 16 core chips. I would expect, and chip photos seem to say, that these are sometimes just pastiches of several 4 core modules. This suggests that they could have different clocks, or, if driven by the same clock, that they may still have iffy phase drift. -- But as for the real question: I doubt that any good software would be broken by differing clock rates.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Womack <twomack@chiark.greenend.org.uk> |
|---|---|
| Date | 2011-11-04 11:13 +0000 |
| Message-ID | <n5e*2ipRt@news.chiark.greenend.org.uk> |
| In reply to | #4619 |
In article <4EB35FE9.1060000@SPAM.comp-arch.net>, Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote: >On 11/3/2011 9:30 AM, Morten Reistad wrote: >> In article<j84sm2$g94$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote: >>> On 10/23/2011 11:58 PM, nmm1@cam.ac.uk wrote: >>>> In article<j82d3u$6lt$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote: >>>>>>> >> >>> I don't think mismatched clock rates will break either the operation of >>> mutexes, of critical sections in general, or of things like message queues. >> >> We already have mismatched clock rates. The current crop of processors >> change speed all the time. Just go look with "Powertop" or some other >> utility. > >AFAIK all of the current generation of multicore chips have all or most >of the processors running at the same basic clock frequency at all >times. I.e. they are all in the same frequency (and voltage) planes. I don't believe that's right, if only because of the big Intel push to turbo; certainly I see systems with one core running at 3.9GHz and three others pretty much stopped, and the slides from IDF claim that in those cases the three others are actually power-gated off. I am reasonably sure that I've seen some cores in my Magny Cours at 1900MHz with other ones on the same chip at 800MHz. Tom
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2011-11-04 10:12 -0700 |
| Message-ID | <8206139.171.1320426775887.JavaMail.geo-discussion-forums@yqpp12> |
| In reply to | #4619 |
On Thursday, November 3, 2011 10:45:45 PM UTC-5, Andy Krazy Glew wrote: > I believe that one of the earliest AMD multicore chips allowed the OS to > set each of the processors to a different frequency. But I believe they > backed away from it, as everyone else seems to have. > > Why? I do not know. Having worked on a multi-CPU design that was completely asynchronous to the main bus (early 1990s), the asynchronous solution is latency intensive. Theoretically it should only take one more flip-flop to transistion from one clock domain to another (3 latches instead of 2) but in practice this becomes 4 latches--one flip-flop in one clock domain and the other in another clock domain. And then thera are all the signals that coordinate the handoff of information through these flip-flops and these tend to cause both more latency and more clock boundary crossings. PLUS the tools don't support this inid of thing. Mitch
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-11-04 09:26 -0700 |
| Message-ID | <j913ot$av1$1@news.albasani.net> |
| In reply to | #4612 |
On 11/3/2011 9:30 AM, Morten Reistad wrote:
> In article<j84sm2$g94$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote:
>> On 10/23/2011 11:58 PM, nmm1@cam.ac.uk wrote:
>>> In article<j82d3u$6lt$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote:
>>>>>>
>
>> I don't think mismatched clock rates will break either the operation of
>> mutexes, of critical sections in general, or of things like message queues.
>
> We already have mismatched clock rates. The current crop of processors
> change speed all the time. Just go look with "Powertop" or some other
> utility.
>
> If we set up a hypervisor and some pretty simple virtualisation we
> can do a simple task switch, and let the single, low-speed cpu be
> master cpu as we finish, and then shut down the other cpus, mapping
> them to the single processor. Inverse action when usage comes back.
>
> If there is consistent, full usage the spindown never happens.
>
I was not claiming it wouldn't work, rather, I was arguing against
someone who predicted gloom and doom from the loss of strict timing
synchronization.
>
>> this is largely about like going and complaining that "rdtsc" is broken
>> because it will give different values and jump forwards/backwards, ...
>> as a thread gets rescheduled from one core to another, or because if one
>> calls rdtsc in a loop, there is some level of "noise" in the returned
>> values (presumably due to whatever else is going on in the system).
>>
>>
>> or such...
>
> We are already there. We may even be a lot better off by replacing the
> 133-633 Mhz speeds of the current high-end processors with a single
> core 600Mhz system; or possibly with multiple register sets for hyperthreading
> so it can better impoersonate all the other processors.
>
this sounds like it is talking about ARM?...
the context in this case was doing something similar in mainstream x86
chips.
I have sometimes wondered though how effectively a dynamic translator
from x86->ARM could be made to work (an issue being the slowdown ratio).
I figure it could probably work with a modest (2x-5x?) slowdown.
32-bit x86 would likely be a little easier, since then one could map
most of the x86 registers into ARM registers, say:
R0/EAX, R1/ECX, R2/EDX, R3/EBX,
R4/EBP, R5/ESP, R6/ESI, R7/EDI,
R8/EIP, R9/EFLAG
...
the normal ARM registers (PC/LR/SP) would continue to operate as normal,
and would essentially manage execution of translated fragments (the PC
and EIP will be different, with EIP pointing to the virtual EIP, and PC
to the translated instructions).
x86-64 would be a little harder, as then one can't map registers 1:1,
and on 32-bit ARM, it would be necessary to introduce a second level of
memory translation (costly) and fake 64-bit registers and operations.
FPU also poses uncertainty (cheaper would be to likely just use doubles,
rather than fake 80-bit floats, but the question is if/how-many apps
would notice?...). a translator could likely infer this though from the
particular load/store operations used.
granted, the main issue is OS support:
many OS's which could support other architectures and modes often don't.
it need not necessarily be a huge issue, but many just don't seem to
want to bother.
it is like with Linux x86-64:
it "could" run 32-bit apps;
however, at least with Fedora, this doesn't seem to work (one can only
run 64-bit apps), unless there is some package somewhere like "32-bit
application libraries" or something ("/lib" is mostly empty, with libs
in "/lib64", ...).
likewise, Win64 "could" have kept 16-bit Windows and DOS apps running at
a secondary level of virtualization/emulation (say, with a more DOSBox
style emulator), but they didn't bother (and were like, "hey, run this
here XPMode thingy"...).
otherwise, all will be as lame awkward emulator apps...
"time to fire up QEMU and run Windows in the thing...".
or such...
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-11-05 11:32 -0400 |
| Message-ID | <%Gctq.21959$yY3.7294@newsfe01.iad> |
| In reply to | #4625 |
BGB wrote: > > > I have sometimes wondered though how effectively a dynamic translator > from x86->ARM could be made to work (an issue being the slowdown ratio). > I figure it could probably work with a modest (2x-5x?) slowdown. > > 32-bit x86 would likely be a little easier, since then one could map > most of the x86 registers into ARM registers, say: > R0/EAX, R1/ECX, R2/EDX, R3/EBX, > R4/EBP, R5/ESP, R6/ESI, R7/EDI, > R8/EIP, R9/EFLAG > .... You could treat the x86/x64 instructions as source code to a compiler and the intel registers as variables. So it becomes not an issue of finding a 1:1 map but rather optimizing the compiler output for ARM. (not my idea - that's a variation on how the VAX assembler was "assembled" (compiled) on Alpha.) Eric
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-11-05 11:55 -0400 |
| Message-ID | <d0dtq.8751$D32.7446@newsfe20.iad> |
| In reply to | #4641 |
EricP wrote: > BGB wrote: >> >> >> I have sometimes wondered though how effectively a dynamic translator >> from x86->ARM could be made to work (an issue being the slowdown >> ratio). I figure it could probably work with a modest (2x-5x?) slowdown. >> >> 32-bit x86 would likely be a little easier, since then one could map >> most of the x86 registers into ARM registers, say: >> R0/EAX, R1/ECX, R2/EDX, R3/EBX, >> R4/EBP, R5/ESP, R6/ESI, R7/EDI, >> R8/EIP, R9/EFLAG >> .... > > You could treat the x86/x64 instructions as source code to > a compiler and the intel registers as variables. > So it becomes not an issue of finding a 1:1 map > but rather optimizing the compiler output for ARM. An emulator has to copy the machine state exactly, but a compiler does not. For example, while many instructions update the EFLAGS, a compiler can use bog-standard dead variable analysis to eliminate all but the ones that effect a conditional branch. By treating the source fixed addresses as labels you don't have to worry about most code and some data size variations. You would also need a "language" run time library, as all compilers do, to handle dynamic stuff. Eric
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-11-05 09:58 -0700 |
| Message-ID | <j93q0v$fvb$1@news.albasani.net> |
| In reply to | #4641 |
On 11/5/2011 8:32 AM, EricP wrote: > BGB wrote: >> >> >> I have sometimes wondered though how effectively a dynamic translator >> from x86->ARM could be made to work (an issue being the slowdown >> ratio). I figure it could probably work with a modest (2x-5x?) slowdown. >> >> 32-bit x86 would likely be a little easier, since then one could map >> most of the x86 registers into ARM registers, say: >> R0/EAX, R1/ECX, R2/EDX, R3/EBX, >> R4/EBP, R5/ESP, R6/ESI, R7/EDI, >> R8/EIP, R9/EFLAG >> .... > > You could treat the x86/x64 instructions as source code to > a compiler and the intel registers as variables. > So it becomes not an issue of finding a 1:1 map > but rather optimizing the compiler output for ARM. > > (not my idea - that's a variation on how the > VAX assembler was "assembled" (compiled) on Alpha.) > it is possible, but would lead to a more complex (and potentially slower) translator. in an offline compiler, one can put lots of effort into finding efficient output, who cares if it takes a good long while?... in a JIT or similar, it is often desirable to keep the translation fast where possible. now, granted, one could probably get by using temporary variables, but in the x86 case, a simple 1:1 mapping works (and leaves several registers left over). this saves from the cost (and complexity) of the translator having to worry about temporaries and register-allocation issues (although this would likely be necessary for x86-64 -> ARM, as a simple/naive mapping will no longer work). I am aware of the costs of things like endlessly recalculating eflags, but in my x86 interpreter a trick was to look at the next several instructions and infer if the eflags update could be skipped. in this case, it used a conservative estimate: would the following instructions invalidate the status flags before they were used? an example of the above being if an arithmetic instruction is followed by another arithmetic instruction which will thrash the status flags (and, in a few cases, one may only need to update certain flags). a less conservative strategy would be to only update eflags if it is detected as having been used in a subsequent instruction, but this could lead to possible cases where eflags doesn't match what it "should" (and contrived code fragments could expose the behavior). granted, I am expecting that a translator would likely have much better performance than my interpreter (which had an approx 70x slowdown, due in large-part to virtual-address translation and similar). or such...
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.arch
csiph-web