From: Simon Kitching Date: 2003-10-03T10:42:54+09:00 Subject: Re: Article on ARTIMA On Thu, 2003-10-02 at 18:10, Lothar Scholz wrote: > JC> Putting aside the fact that on Windows there are some really pathological > JC> threading issues... does the fact that Ruby doesn't support "native threads" > JC> means Ruby will not take advantage of multiple processors (and > JC> pseudo-multiprocessors, like Intel's HyperThreading)? I don't know much > > Yes thats right ! Yes, it is. If an application implements threading at the "user-space" level, then the kernel sees the app as one thread, and therefore cannot distribute processing over multiple physical processors. > One of the reasons why it is not the best language for larger server > applications where at least dual processors are very common. Of couse > you can use multiple processes, but then you will see much harder IPC > and caching problems if you don't use one fat central database server. > > JC> about the microprocessor industry but from what little I know, it seems like > JC> at least some of the big companies are looking to multiple cores and other > JC> parallelism at the thread level for their future chips. Yep, I'd agree with this too. With the proviso, of course, that the vast majority of programs are not multi-threaded internally, and therefore don't run any faster on multi-cpu systems no matter what. > > That's right and it's the right way. But i think the NUMA architecture > will win (long term future). With NUMA (Non unified memory > architecture) you don't have a shared memory anymore - so the ruby way > is not so bad. Numa does have shared memory; it's just that memory "local" to the CPU is faster to access than memory "local" to some other CPU. I do think NUMA is going to win on very big servers, but is unlikely to come to a desktop system - though I'm not an expert here. Have you heard of the "Parrot" project? A team of developers are building an open-source high-performance virtual machine for "interpreted" languages. Their initial target is Perl6, but the expicitly want to support other languages including Python and Ruby. >From the FAQ: "Ideally, Parrot can be used to support other dynamic, bytecode-compiled languages such as Python, Ruby and Tcl." There are some really smart people working on this one, and the project is coming along nicely it seems. Re parrot, see: * http://www.parrotcode.org/ * http://dev.perl.org/perl6/ * http://www.sidhe.org/~dan/blog/archives/000151.html I presume Parrot supports kernel-level multithreading, though I guess some of the Ruby libraries would need work on threadsafety to run correctly in kernel-threading-mode... There was a project called "Cardinal" to implement Ruby on Parrot. It appears to be defunct though (so appropriate for us Monty Python fans :-). Or maybe just dormant until Parrot is more advanced... Re Ruby on Parrot, see: * http://www.rubyxml.com/parrot/parrot_notes.html * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/76623 * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/76552 * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/29980 * http://www.rubygarden.org/ruby?CardinalProject Does anyone here know any more on the status of ruby-for-parrot projects? Cheers, Simon