How Many Processor Cores Are Enough?
|
From: jacko on 24 Oct 2006 16:23 Nick Maclaren wrote: > In article <956dnSONVbw5oaPYnZ2dnUVZ_v6dnZ2d(a)comcast.com>, > Joe Seigh <jseigh_01(a)xemaps.com> writes: > |> > |> [ transactional memory ] > |> > |> My impression is it's a giant load reserved/store conditional but not using > |> registers, just memory. Cache seems to be the mechanism they're > |> playing with to do this, at least according to one Sun patent > |> I saw. The big problem is guaranteeing sufficient forward > |> progress to make it workable. ... > > Quite. That is a classic problem in queuing theory, and it is well- > known to be insoluble in the general case. Like SO many other things, > you push it beyond its limit and it jams or breaks. > > |> Some amount of > |> concurrency will still be exposed at the application level and you > |> will need someone who knows how to deal with that. > > Which is where all these silver bullets fail - if the programmer can't > shoot or is trying an impossible shot, it doesn't matter WHAT his gun > is loaded with .... > > > all this prefetch bollox ties up the smp bus anyhow RISC man RISC > Nick Maclaren.
From: Chris Thomasson on 24 Oct 2006 18:58 "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> wrote in message news:453e3ee4$0$1351$834e42db(a)reader.greatnowhere.com... > Del Cecchi wrote: [...] > 2) It states that the x86 allows "Loads Reordered After Stores". > He does not define this non standard terminology, but if it means > what it sounds like then he is claiming that the x86 allows > a later store to bypass outstanding earlier loads. > That is wrong. On current x86 loads and stores are as follows: void* load(void **p) { void p* = *p; membar #LoadStore | #LoadLoad; } void store(void **p, void *v) { membar #LoadStore | #StoreStore; *p = v; } That means that: static void *g_loc1, *g_loc2; OP1: store(&g_loc1, 0); OP2: load(&g_loc2); x86 can be reorder OP1 and OP2... The store-release barrier in OP1 doesn't prevent the subsequent load-acquire in OP2 from rising above it...
From: Chris Thomasson on 24 Oct 2006 19:23 "Chris Thomasson" <cristom(a)comcast.net> wrote in message news:KPidnb4KTMA7CqPYnZ2dnUVZ_t2dnZ2d(a)comcast.com... > "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> wrote in message > news:453e3ee4$0$1351$834e42db(a)reader.greatnowhere.com... >> Del Cecchi wrote: > > [...] > On current x86 loads and stores are as follows: I should say atomic loads/stores.
From: Eric P. on 24 Oct 2006 22:03 Chris Thomasson wrote: > > "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> wrote in message > news:453e3ee4$0$1351$834e42db(a)reader.greatnowhere.com... > > Del Cecchi wrote: > > [...] > > > 2) It states that the x86 allows "Loads Reordered After Stores". > > He does not define this non standard terminology, but if it means > > what it sounds like then he is claiming that the x86 allows > > a later store to bypass outstanding earlier loads. > > That is wrong. > > On current x86 loads and stores are as follows: > > void* load(void **p) { > void p* = *p; > membar #LoadStore | #LoadLoad; > } > > void store(void **p, void *v) { > membar #LoadStore | #StoreStore; > *p = v; > } > > That means that: > > static void *g_loc1, *g_loc2; > > OP1: store(&g_loc1, 0); > > OP2: load(&g_loc2); > > x86 can be reorder OP1 and OP2... The store-release barrier in OP1 doesn't > prevent the subsequent load-acquire in OP2 from rising above it... No, they are defined in the manual. I quoted the relevant line of text, which you have excised. I don't know exactly what your definitions are, but your load definition appears to be in error because it seems to disallow read bypasses which are explicitly allowed, as per the guide. Eric
From: Chris Thomasson on 24 Oct 2006 22:35
"Eric P." <eric_pattison(a)sympaticoREMOVE.ca> wrote in message news:453ec796$0$1355$834e42db(a)reader.greatnowhere.com... > Chris Thomasson wrote: >> >> "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> wrote in message >> news:453e3ee4$0$1351$834e42db(a)reader.greatnowhere.com... >> > Del Cecchi wrote: >> >> [...] >> >> > 2) It states that the x86 allows "Loads Reordered After Stores". >> > He does not define this non standard terminology, but if it means >> > what it sounds like then he is claiming that the x86 allows >> > a later store to bypass outstanding earlier loads. >> > That is wrong. >> >> On current x86 loads and stores are as follows: >> >> void* load(void **p) { >> void p* = *p; >> membar #LoadStore | #LoadLoad; >> } >> >> void store(void **p, void *v) { >> membar #LoadStore | #StoreStore; >> *p = v; >> } >> >> That means that: >> >> static void *g_loc1, *g_loc2; >> >> OP1: store(&g_loc1, 0); >> >> OP2: load(&g_loc2); >> >> x86 can be reorder OP1 and OP2... The store-release barrier in OP1 >> doesn't >> prevent the subsequent load-acquire in OP2 from rising above it... > > No, they are defined in the manual. > I quoted the relevant line of text, which you have excised. > > I don't know exactly what your definitions are, but your load > definition appears to be in error because it seems to disallow > read bypasses which are explicitly allowed, as per the guide. Are you saying x86 can behave like the Alpha wrt dependant-load barriers? loads/reads can bypass stores/writes : http://groups.google.com/group/comp.programming.threads/msg/b0ab2c4405d1c2c6 That is why you can use a normal store to unlock a spinlock on current x86 Take a look at Petersons Algorithm on x86: http://groups.google.com/group/comp.programming.threads/browse_frm/thread/c49c0658e2607317 it has to call an explicit mfence because of the reordering issue... |