processes vs threads

[Todd Bell]

Does anyone know why a process with 2 threads is slower then 2 processes with a single thread?

[Jeff Schussele]

Hi Todd,

In theory there shouldn't be any difference *as long as* they're doing the same thing.
The system should treat them the same.
Each process OR thread is a scheduable, runnable entity that requires it's own kernel stack, user area, etc.
The difference should boil down to what kind of work & what else is required (disk I/O, Net I/O, etc.) to get that work done as well as how the work is getting done. It's amazing to see the performance difference caused by using the 3 different kinds of fork()s available.
A.T.& T's original fork(). The BSD new & improved vfork(). And the HP copy-on-write in the parent & copy-on-access in the child fork().

HTH,
Jeff

[Todd Bell]

It doesn't seem to be the case. I've taken a test process that has no threads and simply linked in the pthread library (still not using any threads). The processing time doubled. The test program simply perfomed calculations in a loop.

pthread library seems to be the biggest culprit in threading performance degradation?

[Sundar_7]

How many processors you have in the system ? - I may not be able to explain the reasons for the pthread() behaviour. which is the OS version ? 10.20 or 11.x. Only from 11.0 , HP-UX supported Kernel threads and thus you would see significant performance incentive for threading your application.

[Todd Bell]

6 processors, hpux 11.0
On top of the pthread test. I've noticed in less isolated cases that running a process with multiple threads is less efficient then multi processes with a single thread (with the same work). This could be RW's threading implementation or something else. But my isolated test of adding pthread library was very significant. Thanks.

[Mike Stroyan · Accepted solution]

When a process is using threads the threadsafe functions in system libraries need to use mutex operations to protect all of their critical sections that access global data. That can add a lot of overhead to those functions.

I have never been a fan of threads. The implicit sharing of almost every process resource is both expensive because of access synchronization and risky because of the requirement for a programmer to identify every critical section. It gets even worse when application authors are tempted to use third party libraries that may or may not be threadsafe.

I feel that most applications that use threading would be better off using a stable pool of processes with explicit allocation of shared memory and interprocess communication.
That confines the cost and risk of shared resources to small specific regions of code.

It isn't fashionable. But it is good engineering.

[David Butenhof]

Arguing "threads vs processes" is no different than "SMP vs clusters of uniprocessors". Both arguments are essentially pointless and foolish. Each strategy has its own unique advantages and disadvantages, and substantial overlap in the middle. Your level of familiarity and comfort with each may be a legitimate (and even large) part of your decision; but to presume it's unreasonable for someone else to make the opposite decision is unfair.

As has been pointed out, enabling multiple threads in a process brings overhead. If you're not EXPLOITING the ADVANTAGES of multithreading in the process, then that overhead is clearly visible as a performance cost. This is like hooking an enormous trailer onto your car without actually carrying anything, and complaining that your gas mileage has suffered even though you're not USING the trailer. You probably wouldn't even think of doing that: so don't think of hooking threads to your process without using them.

A comparison between "a process with 2 threads" and "2 processes" is inherently flawed because it's not possible for both cases to be running identical code. There are differences, and probably SUBSTANTIAL differences, between those two programs that are not expressed in the description. They may accomplish the same thing, but they still do it in vastly different ways. (And in fact, if they DON'T, then one or the other is simply wrong and that may well explain the differences...)