Multi-processor problems

[Kian-Tat Lim]

	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 at wagvax.caltech.edu, KTL @ CITCHEM.BITNET, GEnie: K.LIM1)