# Benefits of Multi-Threading? **URL:** \ **Category:** Ruby\ **Created:** [January 28, 2007, 3:28pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660 "2007-01-28T15:28:34Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nanostuff](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/eb9ed0/32.png) [@nanostuff](https://www.ruby-forum.com/u/nanostuff)\ **Post date:** [January 28, 2007, 3:28pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660/1 "2007-01-28T15:28:34Z")
I’m slowly going through the pickaxe, and i’ve hit the multi-threading chapter. Despite all the juicy information, I can’t seem to gather what the actual benefits of multi-threading on a single processor are. Is performance improved despite the limitations of one processor, or is there a completely performance unrelated purpose to multi-threading that I missed entirely? On another note, how does shared hosting like Dreamhost handle parallel processing? (I know this is irrelevant in relation to Ruby’s multi-threading), but merely for future reference… will the host allow your application to use up as many of it’s processors as it sees fit, or will it simply refuse to run? Thanks a bunch! ---
**Author:** ![nanostuff](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/eb9ed0/32.png) [@nanostuff](https://www.ruby-forum.com/u/nanostuff)\ **Post date:** [January 28, 2007, 5:21pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660/2 "2007-01-28T17:21:59Z")
On Sun, 28 Jan 2007, NanoStuff wrote: > I’m slowly going through the pickaxe, and i’ve hit the multi-threading > chapter. Despite all the juicy information, I can’t seem to gather what > the actual benefits of multi-threading on a single processor are. > > Is performance improved despite the limitations of one processor, or is > there a completely performance unrelated purpose to multi-threading that > I missed entirely? Sometimes it is convenience. For instance, if there’s an action that you want to have repeated every 5 minutes, you might create a thread just runs in a loop, sleeping for 300 seconds, then performing the action. Threads can also be a useful strategy when accepting outside events. For instance, with a web server one might want to spawn a thread for each connection. The only time you will realize a performance boost from Ruby threads, though, is when there is some time consuming, but non-blocking delay in one thread that allows other threads to use that time in order to get something done. In my experience, they are less about performance than they are about implementation convenience. Kirk H. ---
**Author:** ![nanostuff](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/eb9ed0/32.png) [@nanostuff](https://www.ruby-forum.com/u/nanostuff)\ **Post date:** [January 28, 2007, 5:30pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660/3 "2007-01-28T17:30:03Z")
NanoStuff schreef: > multi-threading), but merely for future reference… will the host allow > your application to use up as many of it’s processors as it sees fit, or > will it simply refuse to run? > > Thanks a bunch! Shared hosting usually lets you use up as much as you want, which explains the poor performance most shared hosts have: people with poorly written scripts end up using a lot of CPU and there is only so much to go around for all clients on the host. When you have threads that run for a really long time, or threads that use up a lot of CPU frequently, your host will most likely mail you to complain about you, and tell you to fix it or get dedicated hosting. Some hosts also have a maximum limit of threads per user, but you shouldn’t worry about that. Wim – Wim Vander S. Bachelor Computer Science, University Ghent [http://nanoblog.ath.cx](http://nanoblog.ath.cx) My weblog, powered by Ruby and BSD licensed. ---
**Author:** ![nanostuff](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/eb9ed0/32.png) [@nanostuff](https://www.ruby-forum.com/u/nanostuff)\ **Post date:** [January 28, 2007, 7:24pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660/4 "2007-01-28T19:24:22Z")
NanoStuff wrote: > multi-threading), but merely for future reference… will the host allow > your application to use up as many of it’s processors as it sees fit, or > will it simply refuse to run? > > Thanks a bunch! There are two main reasons for using multi-threaded applications, even on a single processor: The first is performance. It’s faster to switch between threads than it is between processes, and it’s (typically) even faster to switch between user-level threads like Ruby has. Also, any asynchrony in your program (like waiting for input) can be exploited so that you can do another task while waiting for something to complete, such as user input, etc. The second reason is that some programs decompose naturally into separate tasks, which can be run in separate threads. This is more of a style reason. Threads allow you to modularize code in a way that makes sense in a lot of situations. That’s kind of the brief version. Most operating system books would have this kind of information. Hope that helps. -Justin ---
**Author:** ![nanostuff](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/eb9ed0/32.png) [@nanostuff](https://www.ruby-forum.com/u/nanostuff)\ **Post date:** [January 28, 2007, 8:00pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660/5 "2007-01-28T20:00:27Z")
removed\_email\_address@domain.invalid wrote: > That’s a bit of a red herring, though. With Ruby’s green threads, every > active (i.e. not sleeping) thread that is added to a single process > reduces the overall throughput of all of the threads, collectively, by a > noticable amount. While two separate processes on a single processor > may have less throughput than two threads in a single ruby process, > those two threads will have less throughput than a single thread. So, a > single thread solution will typically be more performant than > multi-thread solution under Ruby’s current threading model. Unless, of course, you use JRuby, which supports full native threads today. - Charlie ---
**Author:** ![nanostuff](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/eb9ed0/32.png) [@nanostuff](https://www.ruby-forum.com/u/nanostuff)\ **Post date:** [January 28, 2007, 7:55pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660/6 "2007-01-28T19:55:26Z")
On Mon, 29 Jan 2007, Justin C. wrote: > There are two main reasons for using multi-threaded applications, even on a > single processor: > > The first is performance. It’s faster to switch between threads than it is > between processes, and it’s (typically) even faster to switch between > user-level threads like Ruby has. Also, any asynchrony in your program (like That’s a bit of a red herring, though. With Ruby’s green threads, every active (i.e. not sleeping) thread that is added to a single process reduces the overall throughput of all of the threads, collectively, by a noticable amount. While two separate processes on a single processor may have less throughput than two threads in a single ruby process, those two threads will have less throughput than a single thread. So, a single thread solution will typically be more performant than multi-thread solution under Ruby’s current threading model. Kirk H. ---
**Author:** ![nanostuff](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/eb9ed0/32.png) [@nanostuff](https://www.ruby-forum.com/u/nanostuff)\ **Post date:** [January 29, 2007, 4:57pm UTC](https://www.ruby-forum.com/t/benefits-of-multi-threading/83660/7 "2007-01-29T16:57:52Z")
On 1/28/07, removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > user-level threads like Ruby has. Also, any asynchrony in your program > > (like > > That’s a bit of a red herring, though. With Ruby’s green threads, every > active (i.e. not sleeping) thread that is added to a single process > reduces the overall throughput of all of the threads, collectively, by a > noticable amount. While two separate processes on a single processor may > have less throughput than two threads in a single ruby process, those two > threads will have less throughput than a single thread. So, a single > thread solution will typically be more performant than multi-thread > solution under Ruby’s current threading model. I’ll second that and add this: Ruby works around the classic green-thread problem (blocking the whole process when a single thread blocks in a system call) by polling a medium-frequency timer interrupt. Total performance in a Ruby program with two threads isn’t just lower than in single-threaded program- it’s a LOT lower.