Hi Guilk, all,
 
    "correct" is a stong word heavily coupled to the paradigm who has made it
born. "Correct" things for procedural processors are procedural languages. We
don't have object oriented processors yet. We are not using decent hardware for
make this technology to run. We are forced to make trade offs due to lack of
better resources.
 
    I'm glad to see that simplicity in the object paradigm is prioritized. I'm
skeptic on extremely complex machines. Specially for scale matters. 
 
    What Igor made is to create a network of squeaks working in one machine as
one. A network scales well. That's a powerful idea. Its simplicity is its
strenght. 
 
    I think the Hydra concept is a pragmatically brilliant choice,
 
    cheers,
 
Sebastian Sastre



________________________________

	De: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] En nombre de Michael van
der Gulik
	Enviado el: Sábado, 23 de Febrero de 2008 00:02
	Para: The general-purpose Squeak developers list
	Asunto: [squeak-dev] The "correct" approach to multi-core systems.
	
	


	On 2/22/08, Stephen Pair <stephen at pairhome.net> wrote: 

		I must say, this is a really impressive development.  I really
think this is the right way to approach multi-core systems. 




	I disagree about it being the right approach in the long term.
	
	In the short term, the Hydra VM allows the use of multiple cores without
large changes to the core of Squeak, which is good and IMHO the right decision
for a quick and reliable solution (for whoever Igor is doing his work for...
Qwaq?). The disadvantage with the Hydra VM is that all inter-process
communication needs to go through a pipe; this makes sharing objects and
synchronising access while still getting good performance more difficult. I
can't back up my claims yet; we'll see how Hydra VM works out.
	
	In the long term, a VM that can run its green threads (aka Process) on
multiple OS threads (aka pthreads) should be the long-term goal. 
	
	I can't imagine that hacking the VM with multiple processes, per-process
state and a global VM lock for garbage collection and new object creation would
be too difficult. The global VM lock would kill scalability and could make
object creation slow, but it should still get some speedup on multi-cored CPUs.
More advanced VMs with per-thread eden space would take a bit longer to write.
	
	Gulik.
	
	-- 
	http://people.squeakfoundation.org/person/mikevdg
	http://gulik.pbwiki.com/