Alex Phillips wrote:
For the purposes of Prime testing, dual-core processors behave exactly
like an SMP mobo with 2 CPUs fitted, however you only get half as much
memory bus bandwidth for each CPU, compared with a proper SMP mobo, so
for "real-world" compute-intensive applications performance can take a
substantial hammering. I've seen figures of over 50% idle on the second
core of a dual-core processor.
This is partly true both for AMD's and Intel's DC CPUs. In case of Intel,
the Smithfield is nothing more than 2 Prescott cores with 1 MB L2 each left in
one
single piece of silicon, connected together via the FSB like in a dual Xeon
system.
Only the "Extreme Edition" could be seen like a 2-way Xeon system at 3.2 GHz
with
FSB 800, because of the still enabled Hyperthreading. But then the memory
throughput
is the same, since in a 2-way Xeon system the two processors - w/o a special
chipset
and 2 independent FSBs - share the FSB and thus also the memory bandwith. And
thanks
to George's most recent optimizations regarding cache usage the memory bus
contention
is really not that much affecting performance anymore as you can see below.
But first a comment on the dual core CPUs from AMD. There are models with 512
kB or 1
MB L2 per core. That and the socket (Opteron/X2) are the only physical
differences.
These CPUs (esp. the Opterons) don't compare that well to a 2-way SMP system, because
the way, how the cores are connected, has changed. It's true, that one memory bank is
missing (which also was the case on some dual Opteron mainboards), but the core w/o
direct access to the memory doesn't have to use Hypertransport for accessing the data
via the other core's memory controller.
In the dual core CPU both cores access the memory in the same way as one core
already
does - via the SRQ (System Request Queue - at least that was the old name).
This is a
2x64 bit connection (bidirectional) at core clock speed. Hypertransport and
memory
controllers appear further down in the hierarchy. So the memory controller sees
the
requests like they would come from one core, while the cache coherancy traffic
goes
over the SRQ at much higher speeds than HT would allow (1 GHz DDR with 2x16
bit).
This is the main difference, which is probably a reason for the good results of
2
instances of Prime95 running on such a dual core.
Now the results:
The most recent page of the "Perpetual benchmark thread" on mersenneforum.org
(http://mersenneforum.org/showthread.php?t=59&page=4) has comparisons of Prime95
running in different configurations on dual cores from AMD and from Intel. In all
cases I used the times for the 4096K FFT.
Pentium D 830 (dual-core 3.0 GHz, no hyperthreading, 1 MB L2 cache per core)
ASUS P5WD2 Premium/WiFi-TV (Intel 955X chipset)
Kingston ValueRAM 2*1GB PC2-4300 ECC memory (DDR2-533 CL4)
Windows XP Professional SP2 (32-bit)
Benchmark/Idle: 143.323 ms.
Benchmark/Torture test (1M FFT): 146.301 ms.
Idle/Benchmark: 142.559 ms.
Torture test (1M FFT)/Benchmark: 144.779 ms.
As it seems (also in the case of the X2), Prime95 running on the first core is
running slower than on the second, very likely thanks to the way, how the
Windows
scheduler is working. So I'll compare changes only on the same core.
Unfortunately
these results are always the best times, not an average time, but the FFT length
should already have caused some averaging effect.
Performance loss of running two instances of Prime95 vs. one is:
~2% on core 0
~1.5% on core 1.
AMD X2 4400+ dual-core (2.2 GHz, 1 MB L2 cache per core), DFI mobo, OCZ memory
Benchmark/Idle: 200.947 ms.
Benchmark/Torture test (1M FFT): 201.461 ms.
Idle/Benchmark: 200.761 ms.
Torture test (1M FFT)/Benchmark: 201.201 ms.
Here the same applies, what I wrote above. And the loss is:
~0.25% on core 0
~0.2% on core 1
It's nice to see, that for both CPUs the impact of running a second instance is
really small, especially on the X2. George did a great job here. Another good thing I
observed is the improved per clock performance for AMD64 CPUs, which is now very
close to the P4's. But anyway the AMD64 CPUs would fare better in regards of
throughput doing TF in 64 bit mode, where they are between ~45 to ~125% faster than
in 32 bit mode thanks to the new code (see
http://mersenneforum.org/showpost.php?p=52715&postcount=21). The same is not true for
EM64T CPUs, very likely because of the way, how the integer division is (had to be)
implemented.
Matthias
_______________________________________________
Prime mailing list
[email protected]
http://hogranch.com/mailman/listinfo/prime
