[squeak-dev] Re: The "correct" approach to multi-core systems.
martin.beck at hpi.uni-potsdam.de
Sat Feb 23 11:55:23 UTC 2008
Michael van der Gulik wrote:
> On 2/23/08, *Andreas Raab* <andreas.raab at gmx.de
> <mailto:andreas.raab at gmx.de>> wrote:
> Jason Johnson wrote:
> > On Sat, Feb 23, 2008 at 4:01 AM, Michael van der Gulik
> > <mikevdg at gmail.com <mailto:mikevdg at gmail.com>> wrote:
> >> I disagree about it being the right approach in the long term.
> > The correct mid-term approach is to do what Erlang did: Have one
> > image, and one OS-thread per *scheduler*. Then when new
> processes run
> > they get a particular scheduler.
> What is the advantage of doing this compared to Hydra?
> Access to shared objects is much easier. In the above scenario, they're
> just there - normal objects - that can be used by multiple Processes
> concurrently. With Hydra, you need some form of inter-image
> communication, which is a lot more work.
you forgot that Erlang doesn't even allow for mutable shared objects. It
only has processes communicating with each other and variables defined
once cannot be changed later on.
Furthermore SMP machines don't scale well for the same reasons global
locks don't scale well. Thus some sophisticated techniques are needed.
NUMA is one of them and starts to completely separate CPUs and their
memory but providing a fast message bus between them.
So while almost any multiprocess architecture not sharing any memory
like Erlang and Hydra (?) will be able to compete with this because they
only rely on message passing, shared memory architectures will stuck on
SMP machines. However, there they will outperform non-shared, I think.
Nevertheless, IMHO shared-memory architectures will always stay more
complex to develop and program with.
More information about the Squeak-dev