[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Chip Multi-threading and the future

Stephen Kellett

6/13/2005 5:58:00 PM

Hi Folks,

Here is an article which is not about Ruby, but is about the future of
computing (re multi-threading and chip multi-threading).

http://www.tbray.org/ongoing/When/200x/2005/06/...

I post this simply because Ruby's support for multi-threading is poor.
If there is one area that needs improvement its multi-threading. When
you read that article its even more apparent that Ruby needs improving
on that front.

Finally at the end he asks "How many threads is enough?". Well for a C++
Thread analysis program I manage, we have many users analyzing in excess
of 64 threads and one up to 600+ threads in a real world situation. No
stats for the Java, Python and Ruby ones though :-(

Anyway, hope you find the article interesting.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/sof...
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
7 Answers

Lothar Scholz

6/13/2005 6:56:00 PM

0

Hello Stephen,

SK> Hi Folks,

SK> Here is an article which is not about Ruby, but is about the future of
SK> computing (re multi-threading and chip multi-threading).

SK> http://www.tbray.org/ongoing/When/200x/2005/06/...

SK> I post this simply because Ruby's support for multi-threading is poor.
SK> If there is one area that needs improvement its multi-threading. When
SK> you read that article its even more apparent that Ruby needs improving
SK> on that front.

Correct. But look at "eval.c" and you know why we need a complete
reimplementation of ruby, there is absolutely no way to add this to
the existing code base. And when i hear Matz comments that YARV will
be integrated into eval.c this winter, then i doubt multi-threading
will be done right.

One problem we share with the python community :-)
They also need a complete python rewrite to handle more then one
thread at a time.

Another solution:

The problem could be easily solved if th OS producer will implement better
thread local store implementation. When a thread local variable has
the same speed as a global one we simply need to fix a few declarations.

And such a thread local store is easy to implement, just switch a few
memory pages inside the MMU when switching threads. Allmost zero
overhead and just a few lines in the thread scheduler. Of course there
must also some linker functionality in the program loader.

I think that this will come much earlier then a rewrite. I hope for
Longhorn as this will be also important for Microsoft.


--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ru...
CTO Scriptolutions Ruby, PHP, Python IDE 's

Eric Hodel

6/13/2005 6:58:00 PM

0

On 13 Jun 2005, at 11:05, Stephen Kellett wrote:

> Hi Folks,
>
> Here is an article which is not about Ruby, but is about the future
> of computing (re multi-threading and chip multi-threading).
>
> http://www.tbray.org/ongoing/When/200x/2005/06/...
>
> I post this simply because Ruby's support for multi-threading is
> poor. If there is one area that needs improvement its multi-
> threading. When you read that article its even more apparent that
> Ruby needs improving on that front.

For web serving, Rails has primarily uses FastCGI, which is a multi-
process model.

43 Things runs our site off of a 2 CPU box with HT enabled, so we get
4 CPUs. The multi-process model works great for this, you don't have
to worry about threads here because of the way Rails is designed.
You do, however, have to worry about memory.

(It would be nice if you could fork(2) a live Rails process so it
wasted less memory, but I think you would loose the benefits of
memory savings the first time the GC runs. Doug Beaver had a nice
presentation about this at the last Seattle.rb meeting, where he
proposed building a separate tree for GC marking...)

But then I need to process the web server's logs, which involves DNS
lookups. This is acceptable but not-so-great because I'm using ruby
threads for that, and that probably chews up more CPU than needed
switching between the 100 threads.

(For reference, 1 worker thread takes about 5 hours, 20 cuts that to
3, and 100 cuts that to 40-50 minutes for files in the 750,000 to
500,000 line range.)

I could rewrite it to be multi-process instead of multi-threading,
but then the code loses its simplicity. I could also rewrite it to
spawn new threads up to N when threads are blocking, but then, again,
I lose simplicity.

> Finally at the end he asks "How many threads is enough?". Well for
> a C++ Thread analysis program I manage, we have many users
> analyzing in excess of 64 threads and one up to 600+ threads in a
> real world situation. No stats for the Java, Python and Ruby ones
> though :-(

So we run 30 FastCGI processes for web serving and 100 ruby threads
for DNS lookup, just for reference.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Eric Hodel

6/13/2005 8:44:00 PM

0

On 13 Jun 2005, at 11:55, Lothar Scholz wrote:

> Hello Stephen,
>
> SK> Hi Folks,
>
> SK> Here is an article which is not about Ruby, but is about the
> future of
> SK> computing (re multi-threading and chip multi-threading).
>
> SK> http://www.tbray.org/ongoing/When/200x/2005/06/...
>
> SK> I post this simply because Ruby's support for multi-threading
> is poor.
> SK> If there is one area that needs improvement its multi-
> threading. When
> SK> you read that article its even more apparent that Ruby needs
> improving
> SK> on that front.
>
> Correct. But look at "eval.c" and you know why we need a complete
> reimplementation of ruby, there is absolutely no way to add this to
> the existing code base. And when i hear Matz comments that YARV will
> be integrated into eval.c this winter, then i doubt multi-threading
> will be done right.

It was my impression that the current eval.c will be replaced
completely with YARV so that nobody has to worry about cutting out
the globals currently in eval.c.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

martinus

6/13/2005 8:47:00 PM

0

> http://www.tbray.org/ongoing/When/200x/2005/06/...

The article mentions Erlang just very briefly. Erlang is especially
designed for concurrency, and allows a lot of simultanuous processes. I
think concurrent design like this will be the future.

--
martinus

gabriele renzi

6/13/2005 10:21:00 PM

0

Martin Ankerl ha scritto:
>>http://www.tbray.org/ongoing/When/200x/2005/06/...
>
>
> The article mentions Erlang just very briefly. Erlang is especially
> designed for concurrency, and allows a lot of simultanuous processes. I
> think concurrent design like this will be the future.
>

but erlang processes are not processes in the OS sense, AFAIR.
Anyway, probably worth investigating :)


FWIW, just loosely related, I'd like to have some kind of "Worker"
concept that could be mapped over green threads, os thread, processes
and whatever based on a common interface. I guess how hard would it be.

gabriele renzi

6/13/2005 10:35:00 PM

0

Stephen Kellett ha scritto:
> Hi Folks,
>
> Here is an article which is not about Ruby, but is about the future of
> computing (re multi-threading and chip multi-threading).
>
> http://www.tbray.org/ongoing/When/200x/2005/06/...

Ah, I think a thing is fun to note: it seem that our dear koichi
sasada is quite involved in cpu-based threading[1], and other parallel
stuff[2]


[1] http://www.atdot.net/yarv/RubyConf2004_YA..., see slide6
[2] http://www.namikilab.tuat.ac.jp/~sasada/public...

Thomas Hurst

6/15/2005 6:09:00 PM

0

* Eric Hodel (drbrain@segment7.net) wrote:

> For web serving, Rails has primarily uses FastCGI, which is a multi-
> process model.

No, FastCGI is a client-server model. A threaded server would be very
nice, although I'm not sure if mod_fastcgi's process manager's aware of
the possibility. Certainly as an external server a threaded app server
would behave identically to a multi-process one, since it's just bog
standard socket ops.

> 43 Things runs our site off of a 2 CPU box with HT enabled, so we get
> 4 CPUs. The multi-process model works great for this, you don't have
> to worry about threads here because of the way Rails is designed.

I don't think Rails does anything special here? As far as FastCGI goes
it works just like any other FastCGI Ruby app.

> You do, however, have to worry about memory.
>
> (It would be nice if you could fork(2) a live Rails process so it
> wasted less memory, but I think you would loose the benefits of
> memory savings the first time the GC runs.

You should be able to; I've been planning on adding support for external
servers and enabling libfcgi's preforking stuff in the C extension for
quite a while. If nothing else you gain proper external server support,
and beyond that there will likely be a lot of sharing with parse trees
and initial data structures.

> But then I need to process the web server's logs, which involves DNS
> lookups. This is acceptable but not-so-great because I'm using ruby
> threads for that, and that probably chews up more CPU than needed
> switching between the 100 threads.

Are there no async DNS libraries for Ruby about? Seems a bit overkill
to use a thread just for a DNS lookup.

--
Thomas 'Freaky' Hurst
http...