I think the "wal-mart argument" is quite an important one. Apart from explicitly creating threads, it would be nice if the Ruby system could be taught to automatically recognize parallelizable code and optimally distribute it across a multiprocessor system -- implicitly. That would be a big advange for high-level programming in general! I do not know the state of the art in this, I only remember that the Atari/Inmos guys failed do do this in Occam, back in the 1980s. Do you think there is a serious chance to get such a thing working?

My first thought concerning "explicit" threads was: Have a look at Erlang (http://www.erlang.org), which is explicitly designed for distributed applications. >20'000 threads per application are not uncommon in large Erlang programs, so I take it for granted that their implementation must be pretty highly optimized. (Don't you ask me which kind of threads is underlying the Erlang VM, though -- concurrency is a grammar-level feature of Erlang). However, it's all about CSPs. No shared memory. So this won't be much of a help, will it?

-- Ruediger Marcus



Am Samstag, 9. April 2005 22:38 schrieb Glenn Parker:
> Avi Bryant wrote:
> > Glenn Parker wrote:
> >>Yes, I want synchronous I/O and true multi-cpu execution.
> >
> > And shared memory - right?
>
> Of course, otherwise threads are no more interesting than (heavy-weight)
> processes.
>
> > Because with Ruby or Smalltalk, there's
> > nothing stopping you from using multiple CPUs by having multiple
> > instances of the VM, communicating through DRb or whatever.
>
> Right, nothing except the overhead and occasional confusion that results
> from passing objects between processes.
>
> > The engineers that build their networking and database
> > systems always claim that the green threads scale much, much better -
> > porting such code from VisualWorks to ObjectStudio always involves a
> > lot of headaches in getting it to perform decently under the
> > disadvantage of native threads.
>
> Yup, I've been there (using C++, not Smalltalk).  If you write code
> assuming that you have "unlimited" threads (which green-style threads
> encourages), some OS threading implementations will really knock you
> flat on your kiester.  If you can redesign to treat threads as limited
> resources (more like processes), native threads excell.  I'm not saying
> one threading style is necessarily "better", they each have their place
> and they each require compromises.
>
> > The best setup would probably be to have many green threads to each (of
> > multiple) native thread, but that's a huge engineering effort.
>
> Sort of like what Solaris already did, and rather nicely at that.
> Sadly, nobody followed in their tracks, or I would have had a lot less
> code to redesign.
>
> > I think
> > Matz made the right decision: keep things simple and under the direct
> > control of the VM.
>
> I assert that a VM can be threaded and still maintain direct control, it
> just won't be quite as simple.

-- 
Chevalier Dr Dr Ruediger Marcus Flaig
   Institute for Immunology
   University of Heidelberg
   INF 305, D-69121 Heidelberg

"Drain you of your sanity,
Face the Thing That Should Not Be."



--
Diese E-Mail wurde mit http://www.mail-inspector.de verschickt
Mail Inspector ist ein kostenloser Service von http://www.is-fun.net
Der Absender dieser E-Mail hatte die IP: 129.206.124.135