I really don't see the advantage of native threads. Ruby threads work fine for most problems. If native threads were included as a separate feature that would be fine (e.g. Thread vs. NativeThread).
Personally I'd prefer not to have to modify code to switch between native and user mode threads. It seems more sensible to me to allow thread model selection via an option to the interpreter - this way you choose the model most appropriate to your application/environment without the need to modify code (even if it is just a require statement)
One primary issue with pure "green" or non-native threads is that a single Ruby process can't scale to more than a single processor (or on hyperthreaded processors, can't leverage hyperthreading. Making Ruby use multiple threads, either
1:1 with the concept of a Ruby thread or some level of
m:n threading, will allow Ruby to scale to multi-processor systems. The latter option,
m:n, would allow green threads to behave much as they do today.
I did recently try to convert a parallel download program from Perl to Ruby, using threads, and I was extremely displeased to see that the speed achieved by Perl was far bigger than the same script simply translated into Ruby. I guess this is linked with the microthreads, and the way they deal with I/O. Switching to native threads would greatly improve the speed (there is no single reason why Ruby would compare so poor to Perl in that case).
To avoid breaking old code, I agree with the idea of creating a new module (native threads can't give the same control functionnalities as the microthreads do, because Ruby can't have any control on the scheduling, as it is the kernel's task to do it).
Finally, I would say that in my own opinion, Threads as currently implemented are more of a tool to write better programs than a way to really handle things in parallel -- cf R.I.N, page 91): they have a different role than native threads.
Multi-processors are getting more and more common in the next months, even in normal home computer and notebooks. Because of that, real parallelism and native threads become more and more important. I'm not sure, if ruby threads should become native ones or these two should be coexisting. I tend to the solution, with both coexisting. This would give everyone the chance to decide, what to use.
How about putting them in the same library, in the same Module under different classes? Ie.
Thread::Native vs
Thread::Old (i can't make up a good classname for current threads though).
If you want green threads, build ruby 2.0 against gnu pth.
Also, ruby's thread performance is not indicative of the performance of green threads in general, but of ruby's implementation of green threads (ruby copies the stack instead of using a separate stack for each thread).
-- Paul Brannan
Personally I'd prefer not to have to modify code to switch between native and user mode threads. It seems more sensible to me to allow thread model selection via an option to the interpreter - this way you choose the model most appropriate to your application/environment without the need to modify code (even if it is just a require statement)
One primary issue with pure "green" or non-native threads is that a single Ruby process can't scale to more than a single processor (or on hyperthreaded processors, can't leverage hyperthreading. Making Ruby use multiple threads, either 1:1 with the concept of a Ruby thread or some level of m:n threading, will allow Ruby to scale to multi-processor systems. The latter option, m:n, would allow green threads to behave much as they do today.
I did recently try to convert a parallel download program from Perl to Ruby, using threads, and I was extremely displeased to see that the speed achieved by Perl was far bigger than the same script simply translated into Ruby. I guess this is linked with the microthreads, and the way they deal with I/O. Switching to native threads would greatly improve the speed (there is no single reason why Ruby would compare so poor to Perl in that case).
To avoid breaking old code, I agree with the idea of creating a new module (native threads can't give the same control functionnalities as the microthreads do, because Ruby can't have any control on the scheduling, as it is the kernel's task to do it).
Finally, I would say that in my own opinion, Threads as currently implemented are more of a tool to write better programs than a way to really handle things in parallel -- cf R.I.N, page 91): they have a different role than native threads.
Multi-processors are getting more and more common in the next months, even in normal home computer and notebooks. Because of that, real parallelism and native threads become more and more important. I'm not sure, if ruby threads should become native ones or these two should be coexisting. I tend to the solution, with both coexisting. This would give everyone the chance to decide, what to use.
How about putting them in the same library, in the same Module under different classes? Ie. Thread::Native vs Thread::Old (i can't make up a good classname for current threads though).
If you want green threads, build ruby 2.0 against gnu pth.
Also, ruby's thread performance is not indicative of the performance of green threads in general, but of ruby's implementation of green threads (ruby copies the stack instead of using a separate stack for each thread).
-- Paul Brannan