On Fri, 1 Sep 2006, Nergal Dimitri wrote:
How much performance do I "miss" when running several instances of a
single threaded application on a multi-core or a system with several
CPUs compared to running a multithreaded application on the same system
(same application but with several threads)? Are there any big
differences in Solaris 10?
Could the performance increase when using zones for the multiple
instances of the same application? (one instance in each zone) If so,
could that match the performance of the multi-threaded application?
Cheers,
Nergal
Hi Nergal,
These questions are a bit too generic to answer, so it's "it depends".
Whether a multithreaded application is faster than multiple instances of a
singlethreaded application depends on the amount of data sharing done,
and/or on the way how parallelism is achieved. I.e. what is your unit of
work ? Some simple generalizations can be made:
- both multithreading and running multiple instances profit from
having more than one CPU (core), as that turns timesliced
multitasking into true, concurrent execution.
- for work that does not share data, parallelism amounts to job
scheduling, i.e. one processing job with its associated data is
started at the same time. In that case, you can achieve the same
with multithreading as with multiple instances; an example here
would be the way the Apache webserver handles requests - one
instance per client served.
- for work that does share data, the overhead of doing so is less
for multithreading than for running multiple instances (and
using IPC mechanisms for data sharing / synchronization).
- there are some types of work that don't lend themselves well to
parallelization. Take for example checksumming - it's CPU bound,
and the time it takes to compress N bytes of data is fixed. A
multi-CPU/multi-core machine may allow you to compress MxN bytes
of data in the same time, if multiple threads request the same
operation - but a single thread running the compression
algorithm will not become faster. Again, "unit of work".
How much you'll gain by going multithreaded compared to staying with
singlethreadedness and running multiple instances depends a lot on the
amount of data sharing you have. See the last item; if all you do is e.g.
compress files, then it doesn't matter whether you spawn N singlethreaded
processes that each compresses one file at a time, or whether you create N
threads that each compresses one file at a time. But if you e.g. want to
accelerate a Gaussian blur on an image taken from your nice new shiny DSLR
camera, creating N threads in Photoshop where each processes 1/Nth of the
lines will make your operation run much faster, and it doesn't help you if
you could've started N Photoshop instances operating on N different
pictures - you only want one...
In that sense, identify your unit of work. Then analyze whether multiple
such units of work share data. If so, you might be able to cut down on the
time per unit of work by splitting this up into parallel subtasks, and
you should attempt to go for multithreading. But if there's no/little data
sharing, you'll benefit from multi-CPU only if you fan out horizontally -
execute multiple work/data "bundles", and that can easily be done by just
spawning off another "job", which might well be singlethreaded.
Hope that's some food for thought,
FrankH.
--------------------------------------------------------------------------
If anything's worth doing, do it with all your heart. The Buddha
Wheresoever you go, go with all your heart. Confucius
Whatever you do, do it with all your heart. St.Paul, Col 3:23
--------------------------------------------------------------------------
_______________________________________________
opensolaris-discuss mailing list
[email protected]
