Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing Threads in Ruby 1.8: A 2-10x performance boost

timetobleed.com

Post reply on HN
Print view View original

1–10 of 15 posts

Re: Fixing Threads in Ruby 1.8: A 2-10x performance boost

#4

Post by ice799 »

scott_s wrote: post #3

Does anyone know what Ruby 1.9 does for creating threads? Does it do something similar to what the author does, or something else entirely?

Hi. Author here.

Ruby 1.9 uses libpthread which creates stacks for its threads in a similar way (mmap and a guard page).

Re: Fixing Threads in Ruby 1.8: A 2-10x performance boost

#5

Post by scott_s »

ice799 wrote: post #4
scott_s wrote: post #3

Does anyone know what Ruby 1.9 does for creating threads? Does it do something similar to what the author does, or something else entirely?

Hi. Author here. Ruby 1.9 uses libpthread which creates stacks for its threads in a similar way (mmap and a guard page).

You mean it calls pthread_create for every Ruby thread? That would mean threads are no longer green threads, since both of the widely used Pthread libraries on Linux (Linuxthreads on 2.4 versions of the kernel, and NTPL on 2.6) have a 1-to-1 mapping of POSIX threads to kernel threads.

Re: Fixing Threads in Ruby 1.8: A 2-10x performance boost

#6

Post by ice799 »

scott_s wrote: post #5
ice799 wrote: post #4

Earlier quoted context omitted.

Hi. Author here. Ruby 1.9 uses libpthread which creates stacks for its threads in a similar way (mmap and a guard page).

You mean it calls pthread_create for every Ruby thread? That would mean threads are no longer green threads, since both of the widely used Pthread libraries on Linux (Linuxthreads on 2.4 versions of the kernel, and NTPL on 2.6) have a 1-to-1 mapping of POSIX threads to kernel threads.

correct. but they each take a global interpreter lock ensuring only one is executing at any given time.

Re: Fixing Threads in Ruby 1.8: A 2-10x performance boost

#8

Post by FooBarWidget »

jcapote wrote: post #7
grandalf wrote: post #2

wow this is a superb post. I wonder why anyone would really want to take the trouble to move to ruby 1.9 anymore... I'd be curious to see the rest of the benchmarks.

I'm curious why someone would go through the trouble to stay on 1.8?

Library compatibility. Many libraries are still not compatible with 1.9. It's good to have interim improvements for 1.8 until the ecosystem has caught up with 1.9, because 1.8 is what actually powers production systems today.

Re: Fixing Threads in Ruby 1.8: A 2-10x performance boost

#9

Post by wheels »

grandalf wrote: post #2

wow this is a superb post. I wonder why anyone would really want to take the trouble to move to ruby 1.9 anymore... I'd be curious to see the rest of the benchmarks.

Note that this is pretty much only measuring thread overhead rather than thread workload throughput. So on an SMP system you'd still have the same problems with blocking I/O and only using one CPU that are part and parcel with green threads. In practice that means for something like a map-reduce pattern on a multi-core system, Ruby 1.9's native threads would win by a significant margin.

Edit: Remembered based on ice799's comment below that in 1.9 the threads still won't be allowed to operate in parallel, which neuters most of the aforementioned benefits to using native threads.

Re: Fixing Threads in Ruby 1.8: A 2-10x performance boost

#10

Post by rbanffy »

FooBarWidget wrote: post #8
jcapote wrote: post #7

Earlier quoted context omitted.

I'm curious why someone would go through the trouble to stay on 1.8?

Library compatibility. Many libraries are still not compatible with 1.9. It's good to have interim improvements for 1.8 until the ecosystem has caught up with 1.9, because 1.8 is what actually powers production systems today.

"Many libraries are still not compatible with 1.9"

It's not likely they will remain so for very long

Post reply on HN