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!
···
--
Posted via http://www.ruby-forum.com/.
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 Haines
···
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?
NanoStuff schreef:
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!
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 Schelden
Bachelor Computer Science, University Ghent
http://nanoblog.ath.cx
My weblog, powered by Ruby and BSD licensed.
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?
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!
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
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 Haines
···
On Mon, 29 Jan 2007, Justin Collins 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
khaines@enigo.com 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
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.
···
On 1/28/07, khaines@enigo.com <khaines@enigo.com> wrote:
On Mon, 29 Jan 2007, Justin Collins 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.