Re: Forking (fwd)

Rogier Wolff (
Sat, 14 Jun 1997 16:12:22 +0200 (MET DST)

Robert Glamm wrote:
> 2) Now, given that you want to extract as much performance as possible
> from your SMP machine, you need to code it on a _machine by machine_
> basis if you want it to run on different platforms. Thus, the portability
> achieved by the threads library is pointless. Given an app coded
> using the threads library and one hand-tuned per machine across
> a bunch of different platforms the hand-tuned ones will win hands down.
> When I say `hand-tuned per platform' I mean taking _all_ of the
> machine's characteristics into account, either at compile-time or at
> run time: L1/L2 cache sizes, time per memory reference, average
> disk access time and transfer rates (if necessary), average semaphore
> contention time between processors, etc. Bottom line: if you tell
> me that your nice portable threads library can do better than
> my (assembly!) semaphore/lock code + hand-tuned SMP code, you're out
> of your mind for any reasonably complex SMP problem.

Robert, I'm not going to tell you that you're not going to win. I'm
going to tell you that your handcoded assembly semaphore/lock stuff is
going to beat the threads library by around 10 to 20 percent. At that
performance difference, I'd say (and some others with me I presume)
just buy a faster processor, or add an extra processor. If you are
going to hand-optimize the code NOW, you will have to do that again
when you switch to a different architecture next year. Use the threads
library, that will lose you 10% now, but you'll save the man-hours
whenever you upgrade to a faster machine.

The Cray/IBM/SGI parallelizing departments are not hand tuning parallel
code. They are parallelizing previously sequential code.

Of course, if you're just doing this project in your spare time, your
man-hours don't cost you anything. You'd rather win the 10% in
performance. If that's the case, you should just ignore the warnings
and implement everything the way you want it......