On Sun, 18 Oct 2009 01:15:45 -0000 Roman Shaposhnik <ro...@shaposhnik.org> wrote: > On Thu, Oct 15, 2009 at 10:53 AM, Sam Watkins <s...@nipl.net> wrote: > > On Wed, Oct 14, 2009 at 06:50:28PM -0700, Roman Shaposhnik wrote: > >> > The mention that "... the overhead of cache coherence restricts the ab= > ility > >> > to scale up to even 80 cores" is also eye openeing. If we're at aprox = > 8 > >> > cores today, thats only 5 yrs away (if we double cores every > >> > 1.5 yrs). > > > > Sharing the memory between processes is a stupid approach to multi-proces= > sing / > > multi-threading. =A0Modern popular computer architecture and software des= > ign is > > fairly much uniformly stupid.
> It is. But what's your proposal on code sharing? All those PC > registers belonging to > different cores have to point somewhere. Is that somewhere is not shared me= > mory > the code has to be put there for every single core, right? Different technoglogies/techniques make sense at different levels of scaling and at different points in time so sharing memory is not necessarily stupid -- unless one thinks that any compromise (to produce usable solutions in a realistic time frame) is stupid. At the hardware level we do have message passing between a processor and the memory controller -- this is exactly the same as talking to a shared server and has the same issues of scaling etc. If you have very few clients, a single shared server is indeed a cost effective solution. When you absolutely have to share state, somebody has to mediate access to the shared state and you can't get around the fact that it's going to cost you. But if you know something about the patterns of sharing, you can get away from a single shared memory & increase concurrency. A simple example is a h/w fifo (to connect producer/consumer but you also gave up some flexibility). As the number of processors increases on a device, sharing state between neighbors will be increasingly cheaper compared any global sharing. Even if you use message passing, messages between near neighbors will be far cheaper than between processors in different neighboorhoods. So switching to message passing is not going to fix things; you have to worry about placement as well (just like in h/w design).
