# Process or Thread?

**URL:** <https://www.ruby-forum.com/t/process-or-thread/174209>\
**Category:** Ruby\
**Created:** [August 22, 2009, 4:30pm UTC](https://www.ruby-forum.com/t/process-or-thread/174209 "2009-08-22T16:30:34Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 22, 2009, 4:30pm UTC](https://www.ruby-forum.com/t/process-or-thread/174209/1 "2009-08-22T16:30:34Z")

</div>

I have a parent application (which I think of as a test harness) that  
wants to invoke a fairly intensive image processing application against  
a directory full of image files. Each image is processed independently.

So, to get performance, I wanted to get the work happening on each of  
those images in parallel. So I could divide the files in the directory  
into two sets, and submit one set for processing in one process/thread  
and the other set in another process/thread. Note that the  
sub-process/threads are almost totally separate from the parent app, so  
relatively little information needs to go back and forth.

Here is what I’ve learned so far from reading two books and lots of  
googling:

One point is that there’s no process support on Windows, which isn’t a  
deal killer for me.

Another point is the operation on multi-core CPUs: processes will, and  
threads will not use the mutliple cores. This too is fairly “don’t care”  
for me.

I am interested in ease of implementation and debugging. And I am also  
very interested in getting the cpu and disk active at the same time as  
there is a fairly large amount of data to be read form the disk.

What are your recommendations?

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 22, 2009, 4:47pm UTC](https://www.ruby-forum.com/t/process-or-thread/174209/2 "2009-08-22T16:47:21Z")

</div>

Pito S. wrote:

> I have a parent application (which I think of as a test harness) that  
> wants to invoke a fairly intensive image processing application against  
> a directory full of image files. Each image is processed independently.

It doesn’t sound like your situation will result in improved performance  
with threads. Things don’t actually get done at the same time with  
threads–that’s an illusion. What happens is that there is very fast  
switching between different tasks. However, if your tasks do not have  
dead time during the processing, then using threads won’t improve  
performance. For instance, suppose you have two tasks that each take 3  
minutes to complete. The processing might happen in this order with  
threads:

## task1: 1 minute task2: 1 minute task1: 1 minute task2: 1 minute task1: 1 minute task2: 1 minute

total = 6 minutes

But if you just ran each task sequentially without using threads, the  
total time would also be 6 minutes. Using threads will only speed up  
processing time if your tasks have idle time when they are doing  
nothing. During that down time, if you switch to another task in  
another thread, then total processing time will be lower.

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 22, 2009, 7:44pm UTC](https://www.ruby-forum.com/t/process-or-thread/174209/3 "2009-08-22T19:44:22Z")

</div>

On Sat, Aug 22, 2009 at 16:47, 7stud – [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Pito S. wrote:

It doesn’t sound like your situation will result in improved performance

> ## task1: 1 minute task2: 1 minute task1: 1 minute task2: 1 minute
> 
> total = 6 minutes

That’s true if you´re running MRI, since it uses “green” threads (i.e.,  
you  
really have a single OS-level thread that gets task-switched by Ruby  
itself). However, if you run on JRuby, the Ruby Thread support gets  
mapped  
onto the Java Thread support, which _does_ map to OS-level threads and  
therefore will take advantage of multiple cores if you have them. In  
that  
case you _would_ get faster processing.

Hope this helps,  
-Mario.

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 22, 2009, 9:08pm UTC](https://www.ruby-forum.com/t/process-or-thread/174209/4 "2009-08-22T21:08:39Z")

</div>

On Aug 22, 2009, at 1:43 PM, Mario C. wrote:

> That’s true if you´re running MRI, since it uses “green” threads  
> (i.e., you  
> really have a single OS-level thread that gets task-switched by Ruby  
> itself). However, if you run on JRuby, the Ruby Thread support gets  
> mapped  
> onto the Java Thread support, which _does_ map to OS-level threads and  
> therefore will take advantage of multiple cores if you have them. In  
> that  
> case you _would_ get faster processing.

For a CPU intensive task (image processing), i doubt that two OS  
threads running on two core’s is going to be any more efficient  
than two processes running on two cores. Multi-threading introduces  
complications that are neatly avoided by using multiple processes.  
I’d much rather deal with a multi-process architecture than a  
multi-threaded architecture.

Gary W.

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 22, 2009, 11:02pm UTC](https://www.ruby-forum.com/t/process-or-thread/174209/5 "2009-08-22T23:02:30Z")

</div>

Gary W. wrote:

> For a CPU intensive task (image processing), i doubt that two OS  
> threads running on two core’s is going to be any more efficient  
> than two processes running on two cores. Multi-threading introduces  
> complications that are neatly avoided by using multiple processes.  
> I’d much rather deal with a multi-process architecture than a  
> multi-threaded architecture.
> 
> Gary W.

Thanks all for your responses.

A note: he files being processed are quite large and numerous. So  
there’s also plenty of file IO that has to happen. In the vanilla ‘green  
thread’ case, would you expect performance improvements, because while  
one thread was blocked for IO the other one could run?

Thanks again,

Pito

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 23, 2009, 6:21am UTC](https://www.ruby-forum.com/t/process-or-thread/174209/6 "2009-08-23T06:21:17Z")

</div>

On Aug 22, 2009, at 5:02 PM, Pito S. wrote:

> A note: he files being processed are quite large and numerous. So  
> there’s also plenty of file IO that has to happen. In the vanilla  
> ‘green  
> thread’ case, would you expect performance improvements, because while  
> one thread was blocked for IO the other one could run?

Whether you use threads or processes your CPU-bound tasks will run while  
your IO-bound tasks are waiting for the disk.

Gary W.

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 23, 2009, 1:33am UTC](https://www.ruby-forum.com/t/process-or-thread/174209/7 "2009-08-23T01:33:14Z")

</div>

Den Sat, 22 Aug 2009 09:30:36 -0500 skrev Pito S.:

> Here is what I’ve learned so far from reading two books and lots of  
> googling:
> 
> One point is that there’s no process support on Windows, which isn’t a  
> deal killer for me.

Not quite. Look in Task Manager, there is a list of processes running.  
What Windows possibly lacks is fork(), the unix way of creating  
processes. It does however have CreateProcess (I think that’s what  
is called), which behaves like fork+exec.

If you split the “controller” process and the “worker” process into  
two different programs, it won’t be a problem. If you insist on  
having them as one program, you’ll need to do a bit more work  
(add a comamnd line argument telling the new process that it’s a  
worker process).

> Another point is the operation on multi-core CPUs: processes will, and  
> threads will not use the mutliple cores. This too is fairly “don’t care”  
> for me.

Native threads will, Ruby green threads won’t.

> I am interested in ease of implementation and debugging.

Debugging is lots easier with processes, as one process cannot  
accidentally overwrite data of another (shared memory is possible,  
but needs to be allocated explicitly).

That may not be as big a problem with Ruby green threads, as the  
runtime knows what each thread is up to.

> And I am also  
> very interested in getting the cpu and disk active at the same time as  
> there is a fairly large amount of data to be read form the disk.
> 
> What are your recommendations?

I would go for processes. But that’s coming from C, where there is no  
runtime keeping track of what each thread is doing. With processes,  
the OS will prevent one OS from overwriting the data of another.

/Kent

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [August 23, 2009, 11:50am UTC](https://www.ruby-forum.com/t/process-or-thread/174209/8 "2009-08-23T11:50:47Z")

</div>

On 23.08.2009 01:28, Kent Friis wrote:

> > I am interested in ease of implementation and debugging.
> 
> Debugging is lots easier with processes, as one process cannot  
> accidentally overwrite data of another (shared memory is possible,  
> but needs to be allocated explicitly).

IMHO a multitude of processes does not necessarily ease debugging. If  
you need to find out which process is running berserk or exhibiting a  
bug that may be more difficult than debugging of a single interpreter  
process. Also, if there are communication issues between two processes  
that may be difficult to debug as well.

Having said that, both approaches are pretty easy to implement, given  
that DRb is a full fledged remote object call feature (similar to RMI  
and CORBA).

Kind regards

robert

---

<div class="post-metadata">

**Author:** ![pitosalas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@pitosalas](https://www.ruby-forum.com/u/pitosalas)\
**Post date:** [September 3, 2009, 7:29am UTC](https://www.ruby-forum.com/t/process-or-thread/174209/9 "2009-09-03T07:29:43Z")

</div>

On Sat, Aug 22, 2009 at 2:07 PM, Gary W.[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> For a CPU intensive task (image processing), i doubt that two OS  
> threads running on two core’s is going to be any more efficient  
> than two processes running on two cores. Â Multi-threading introduces  
> complications that are neatly avoided by using multiple processes.  
> I’d much rather deal with a multi-process architecture than a  
> multi-threaded architecture.

You’re correct, if the processes don’t talk to each other. But if you  
have to pass information across processes, things suddenly get a lot  
more tangled and IPC-bound than with threads. It’s a tradeoff, as  
always.

- Charlie