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.
Hi,

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.

Regards,
Martin