topic Re: processes vs threads in Operating System - HP-UX

processes vs threads

Todd Bell — Tue, 31 Aug 2004 14:28:49 GMT

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

Re: processes vs threads

Jeff Schussele — Tue, 31 Aug 2004 14:43:49 GMT

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

Re: processes vs threads

Todd Bell — Tue, 31 Aug 2004 15:05:29 GMT

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?

Re: processes vs threads

Sundar_7 — Tue, 31 Aug 2004 15:18:56 GMT

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.

Re: processes vs threads

Todd Bell — Tue, 31 Aug 2004 15:37:11 GMT

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.

Re: processes vs threads

Mike Stroyan — Wed, 01 Sep 2004 10:54:11 GMT

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.

Re: processes vs threads

David Butenhof — Wed, 01 Sep 2004 12:07:25 GMT

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...)