Re: Forking (fwd)
Rogier Wolff (R.E.Wolff@BitWizard.nl)
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......
Roger.