David, On Sun, 2011-02-27 at 10:40 -0500, dsimcha wrote:
> I realized the obvious kludge and "fixed" this. Now, all benchmarks
> take a --nCpu command line argument that allows you to set the number of
> cores manually. This is an absolute must if running on 64. If you
> don't set this, the default is whatever core.cpuid.coresPerCPU returns,
> and on 64 bit this will always be 1.
I agree it is sad to have had to do this, core.cpuid.coresPerCPU should
be fixed and fixed asap. In the interim using "--nCpu 8" with the
64-bit build on Ubuntu Maverick, I get:
======== euclidean ============
Serial reduce: 1154 milliseconds.
Parallel reduce with 8 cores: 266 milliseconds.
======== matrixInversion ============
Inverted a 256 x 256 matrix serially in 62 milliseconds.
Inverted a 256 x 256 matrix using 8 cores in 88 milliseconds.
======== millionSqrt ============
Parallel benchmarks being done with 8 cores.
Did serial millionSqrt in 957 milliseconds.
Did parallel foreach millionSqrt in 212 milliseconds.
Did parallel map millionSqrt in 164 milliseconds.
======== parallelSort ============
Serial quick sort: 4548 milliseconds.
Parallel quick sort: 1502 milliseconds.
======== pi ============
Calculated pi = 3.141596556 in 172 milliseconds serially.
Calculated pi = 3.141596794 in 41 milliseconds using 8 cores.
======== pipelining ============
Did serial string -> float, euclid in 2047 milliseconds.
Did parallel string -> float, euclid with 8 cores in 1756 milliseconds.
I get the feeling that the pi calculation is showing that the perhaps
the computations are too short to show proper scaling?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected]
41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
