[Tfug] CPU Query

[Brian Murphy]

Quoting Jim Secan <jim at nwra.com>:
> I'm thinking I'll probably go with a 2X since it doesn't cost that much
> more.  If I run some benchmarks (I have some other 2GHz-level Athlon64
> systems that I can also run on) I'll post what I get.  I've calculated
> that the run I am planning would take 260 hours on an existing 1.8 GHz
> Athlon64, but I can break it into 1h chunks for benchmarks.  If the OS can
> configure itself to use only one side of a 2X system, that might be
> another interesting benchmark to try.  I know OS X indicates it can handle
> this sort of configuration (although I don't know how well, 'cause I don't
> have a 2X Mac).
>



Linux will present a dual core processor as 2 CPUs.  Just like in a dual
single core system, your single threaded process will only run as fast
as a single core runs.  With multiple processors you may gain a
marginal benefit on single processor jobs because the linux scheduler
will run the normal background processing on one CPU core (syslog,
cron, ssh, etc) and your compute intensive job on the other core.  You
could even go further and use the 'taskset' command to bond your job to
a CPU core.  If taskset isn't installed by default, it can be found in
the schedutils package.  Linux and a dual core processor won't do any
parallelization magic to single threaded jobs.  I would second the
recommendation that a large CPU cache may boost your performance
significantly if your calculations fit within the cache.  It sounds
like you may not have the luxury of benchmarking various CPUs to
discover if this is the case.

As for testing a single side of the processor, boot a uniprocessor
kernel or pass the maxcpus=1 parameter to your standard SMP kernel.

Finally, since you can split your job, consider if you can run 2
instances on your dual core system to further reduce your run time.

Brian

The opinions or statements expressed herein are my own and should not be
taken as a position, opinion, or endorsement of the University of
Arizona.