Getting locks and sharing: was RE: Getting concurrency

[Roger Larsson]

What about serialising data sent "externally".
Isn't all data sent between nodes serialised?
(for architecture and release independence)
Or does Erlang optimise the case where both nodes are equivalent?

On Friday 17 June 2005 09.38, Joe Armstrong (AL/EAB) wrote:
> IMHO the single most important design "boundary" is the inter-processor
> boundary. Today there are 3 different RPC's:
>
> 	RPC1 - between two processes in the same Erlang node
same node => same processor and Erlang release

> 	RPC2 - between two processes in different nodes in a single CPU
different nodes => could be different Erlang releases, especially if used
during upgrades of the run time environment.

> 	RPC3 - between two processes in different nodes on different CPU's
different nodes & different CPUs => probably different Erlang releases too

>
> The times for these are *vastly* different RPC1 is in microseconds, RPC3 is
> in millisceconds.
>
> When we have multi-core CPUs well have:
>
> 	RPC4 - between two processes in different nodes in different CPUs on the
> same chip

The system architect should be able to choose if he like to use
* two nodes for separation
* single node for less communication overhead (no serialisation required)
* why not native OS threads (one per process) [yes I know, but there might be 
  some application that benefit]
* something like Erlang process groups - group which Erlang processes runs 
better with same processor or data available.
 * a mix of all possibilities above!
 [First select what needs to be protected from each other,
 Then assume "unlimited" no of processors - OK, possible? (no dynamic process
 creation)
 or why not a limited but big no of processors - which processes SHOULD run 
together, for optimum performance?

BTW there are even mixed-core chips:
 RPC5 - two nodes with different CPU's on one chip (using shared memory) for
  communication.
 Examples:
	The Cell
	Texas Instruments: ARM+DSP

/RogerL