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!
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.
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
My weblog, powered by Ruby and BSD licensed.
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
[email protected] 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.
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.
On 1/28/07, [email protected] [email protected] 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.