Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Date | 2011-05-13 19:53 +0200 |
|---|---|
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
| Newsgroups | comp.arch |
| Subject | Re: What are the various alternate uses for the PC's LSB ? |
| References | <9226d60e-0c97-4863-97ab-1fc568a7bb46@glegroupsg2000goo.googlegroups.com> <iqhv4i$bg8$1@speranza.aioe.org> <4DCCA664.9070207@SPAM.comp-arch.net> <nqev98-qvt2.ln1@ntp6.tmsw.no> <iqjjk2$ldo$1@dont-email.me> |
| Message-ID | <op70a8-sru2.ln1@ntp6.tmsw.no> (permalink) |
Stephen Fuld wrote: > On 5/13/2011 3:47 AM, Terje Mathisen wrote: > > snip > >> Personally I prefer algorithms which can use XADD, i.e. atomic >> fetch_and_add(), specifically because they can provide guaranteed >> forward progress, with minimum bus uglyness. > > I agree with your preference and would add another reason. There are > applications where a system wide unique, guaranteed increasing > number is exactly what is needed. Think transaction numbers in some > transaction systems. XADD provides this with minimal cost. I know that such numbers are very useful, but I would really prefer to avoid the need for them, because they do end up as a global bottleneck. > > >> It should also be relatively easy (for hw) to propagate an XADD >> operation across a mesh and handle it at the location of the target >> memory. > > Yes. Although test and set is perhaps easier to do this with. But see > below Test&Set, in the form XCHG reg,[mem] is the original x86 sync primitive, the main problem is that it only provides a boolean gate, not something which can be used as-is. [snip] > itself. However, at the cost of that elegance, perhaps a reasonable > compromise would be to handle the addition within the memory > controller chip (or part of chip) instead of the RAM chips. This > still avoids the need for bus locks/snoops. It would cost a second > transfer at the RAM chips themselves, but since many/most RAM to > controller interfaces are 64 bits wide, it makes the overflow problem > small enough that you might be able to not implement anything special > for it. I'm currently assuming that any distributed RMW facility has to be implemented in the memory controllers... Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: What are the various alternate uses for the PC's LSB ? "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-12 08:49 -0700
Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-13 02:01 +0200
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-12 20:32 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 12:47 +0200
Re: What are the various alternate uses for the PC's LSB ? Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-13 08:44 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 19:53 +0200
Re: What are the various alternate uses for the PC's LSB ? Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-13 11:36 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 22:26 +0200
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 17:17 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-16 14:22 +0200
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-16 07:38 -0700
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 17:14 -0700
Re: What are the various alternate uses for the PC's LSB ? rpw3@rpw3.org (Rob Warnock) - 2011-05-13 07:45 -0500
csiph-web