Path: utzoo!attcan!uunet!ns-mx!ceres!zaphod.mps.ohio-state.edu!wuarchive!usc!elroy.jpl.nasa.gov!cit-vax!ktl
From: ktl@wag240.caltech.edu (Kian-Tat Lim)
Newsgroups: comp.sys.sgi
Subject: Re: Multi-processor problems
Message-ID: <13229@cit-vax.Caltech.Edu>
Date: 12 Jan 90 18:52:20 GMT
References: <9001120157.AA15338@smithkline.com>
Sender: news@cit-vax.Caltech.Edu
Reply-To: ktl@wag240.caltech.edu (Kian-Tat Lim)
Organization: California Institute of Technology, Pasadena, CA
Lines: 41
In-reply-to: dixons%phvax.dnet@SMITHKLINE.COM


	On our 4D/240GTXB running 3.1F, we have observed similar
effects.  For a small, nearly-completely parallelizable program, here
are some representative timings (the compute-bound job was running in
the background while these tests were run):

1 compute-bound job + 1 thread:  14.5u 0.1s 0:14 98%
1 compute-bound job + 2 threads:  7.0u 0.1s 0:07 98%
1 compute-bound job + 3 threads:  4.9u 0.1s 0:05 98%
1 compute-bound job + 4 threads:  6.5u 0.1s 0:07 87%
1 compute-bound job + 5 threads: 17.0u 0.1s 0:26 65%
1 thread alone: 14.5u 0.1s 0:14 98%
2 threads alone: 7.0u 0.1s 0:07 96%
4 threads alone: 3.8u 0.1s 0:04 96%

A computation-less version of the same program that just did m_forks
was timed as follows (without the compute-bound background job):

1 thread:   0.3u 0.1s 0:00 73%
2 threads:  0.3u 0.0s 0:00 86%
3 threads:  0.3u 0.1s 0:00 82%
4 threads:  0.3u 0.1s 0:00 81%
5 threads: 18.9u 0.1s 0:28 66%

Multiple parallel jobs ("time cmd & time cmd")

2 x 2 threads: 7.4u 0.1s 0:07 98%
2 x 4 threads: 34.0u 0.1s 1:08 49%

Increasing the computation per thread by 25 times gave:

4 threads: 109.0u 1.1s 1:50 99%
2 x 4 threads: 150.8u 7.4s 5:11 50%

	There appear to be severe scheduling problems with more than
four simultaneous threads of execution.  We're in the process of
confirming these numbers and sending a letter to SGI; if someone has a
fix, we'd love to hear it.

--
Kian-Tat Lim (ktl@wagvax.caltech.edu, KTL @ CITCHEM.BITNET, GEnie: K.LIM1)