14 Nov
2007
14 Nov
'07
11:32 p.m.
On Nov 14, 2007 11:43 AM, Dave McGuire <mcguire at neurotica.com> wrote:
On Nov 14, 2007, at 12:48 PM, Eric J Korpela wrote:
You are correct, I should have said "modern single-threaded
processor." If you multithread your
application code and run it on a CPU with multiple hardware threads
you should be able (best case) to turn than 90% into 90%^N where N is
the number of truly independent hardware threads. In other words,
with two threads each thread spends 90% of the time waiting, so overal
the processor is only spending 81% of the time waiting, which would
nearly double the processor performance.
In reality you probably won't get there, though. Especially in Intel
(Prescott?) hyperthreading where the threads share a register file and
execution unit, you're lucky to get down to 87% of time waiting for
memory. That also assumes you've designed your code properly so that
the threads don't contend for the same cache lines.
Don't know too much about the Niagara equivalent, but for my purposes
(numerics) the flaw of Niagara was all the cores shared the same FPU.
I guess that was fixed in Niagara II, though.
Eric
Not that it matters that much anyway since a
modern processor on
non-trivial code is spending 90% of its cycles waiting for memory.
A few thousand cycles for an interrupt is nothing...
This isn't the case with some architectures. Intel's
HyperThreading is designed to address this problem, but it is broken
in its current implementation. Sun's Niagara architecture
(UltraSPARC-T1 and -T2) deals with it successfully.