Dual Core chips??

On Sat, 18 Nov 2006 21:13:00 -0700, ray wrote:

On Sat, 18 Nov 2006 12:56:27 -0500, krw wrote:

A dual core system *IS* a two CPU system.

It is and it ain't. It is still not as efficient as two cpus on two
different chips - there are some shared resources that slow things down.

For instance?

On Sun, 19 Nov 2006 17:16:42 GMT, PdL wrote:

On Sat, 18 Nov 2006 23:18:17 -0500, daytripper wrote:

A dual core system *IS* a two CPU system.

It is and it ain't. It is still not as efficient as two cpus on two
different chips - there are some shared resources that slow things down.

For instance?
I haven't actually met the difference with an smp system in real life
applications. However, unlike smp, multiple cores share the same memory
bus. That's the reason why of their huge L2.

But....every Intel x32 multi-processor platform shares the same *memory bus* -
whether it uses a multi-dropped "front side bus" or separate pipes to the
shared memory controller.

A memory reference made by any processor - or any core within - has to undergo
the same coherency checks regardless of cache organization/distribution - and
if it misses it still resolves to the same ranks of ram.

There's no functional difference if the platform is a single socket multicore
or a multi-socket single core. Coherency traffic happens. And, ultimately, the
real throughput choke point is shared - at the dimms - regardless of
processor/core topology.

Thus, I fail to see a distinction that actually matters. And if you happen to
see a copy of the latest Clovertown benchmarks, I doubt you'll disagree...

Cheers

/daytripper

daytripper wrote:

There's no functional difference if the platform is a single socket multicore
or a multi-socket single core. Coherency traffic happens. And, ultimately, the
real throughput choke point is shared - at the dimms - regardless of
processor/core topology.


On the subject of coherency, I quickly become incoherent.

If processors actually share L2 then why isn't it possible for closely
cooperating threads to use the same data without touching main memory,
or without being held up waiting for main memory?

I seriously doubt if anyone will go to the trouble to do this, since
people have a hard enough time writing correct multi-threaded code
without worrying over such niceties, but there are some latency-hiding
tricks one might be tempted to try with two closely-cooperating threads
(lots of stuff in the literature).

Robert.

In article .com,
says...
daytripper wrote:

There's no functional difference if the platform is a single socket multicore
or a multi-socket single core. Coherency traffic happens. And, ultimately, the
real throughput choke point is shared - at the dimms - regardless of
processor/core topology.


On the subject of coherency, I quickly become incoherent.

If processors actually share L2 then why isn't it possible for closely
cooperating threads to use the same data without touching main memory,
or without being held up waiting for main memory?

That's certainly a possibility, but it's a architecture trade-off.
Not sharing L2s is good for performance when they have little
common data.

I seriously doubt if anyone will go to the trouble to do this, since
people have a hard enough time writing correct multi-threaded code
without worrying over such niceties, but there are some latency-hiding
tricks one might be tempted to try with two closely-cooperating threads
(lots of stuff in the literature).

I think you're right, though the concept of "helper threads" isn't
new. In fact this is what prefetching hardware (and software
hinting) tries to do.

--
Keith

George Macdonald wrote:

Current dual core chips are backed off on clock speed slightly from
what can be done with a single core but not by much... and not enough
where you'd regret getting the dual vs. the "faster" single-core.


Only on Intel systems.

AMD won the performance crown over many years because it threw out the
'more cpu cycles, the faster the processor' dogma of previous
architectures. It developed more efficient processors that did more per
cycle and so its cpus preformed much better and ran a lot cooler than
Intel's electric heaters. Its dual-cores were/are exactly the same as
the signle core equivalents.

Now that Intel has taken this onboard and released some very efficient
processors which run with slower clock cycles than the previous
pentiums (pentium Ms excluded) it has regained the performance crown
after many years of playing second fiddle to AMD.

George Macdonald wrote:

Just drop the hyperthreading idea - the current top performers, Core 2
Duo and Athlon64 X2, do not have it.


And don't need it.

HT was just a kludge by Intel to try and squeeze some more performance
(and marketting collateral) out of the P4 when it realised that the
net-burst architecture was not working as well as they had hoped. For
some applications HT actually slowed things down.

"krw" wrote in message
...
In article .com,
says...
, I quickly become incoherent.

If processors actually share L2 then why isn't it possible for closely
cooperating threads to use the same data without touching main memory,
or without being held up waiting for main memory?

That's certainly a possibility, but it's a architecture trade-off.
Not sharing L2s is good for performance when they have little
common data.

I seriously doubt if anyone will go to the trouble to do this, since
people have a hard enough time writing correct multi-threaded code
without worrying over such niceties, but there are some latency-hiding
tricks one might be tempted to try with two closely-cooperating threads
(lots of stuff in the literature).

I think you're right, though the concept of "helper threads" isn't
new. In fact this is what prefetching hardware (and software
hinting) tries to do.

If the caches are shared, and the data is in the cache for CPU1, then CPU2
can most certainly access it. This is automatic and requires no special
programming. I get the impression that Myers wants to do special
programming to make it possible to share what's already available! Or am I
making a really dumb mistake? ;-)

In article et,
says...
"krw" wrote in message
...
In article .com,
says...
, I quickly become incoherent.

If processors actually share L2 then why isn't it possible for closely
cooperating threads to use the same data without touching main memory,
or without being held up waiting for main memory?

That's certainly a possibility, but it's a architecture trade-off.
Not sharing L2s is good for performance when they have little
common data.

I seriously doubt if anyone will go to the trouble to do this, since
people have a hard enough time writing correct multi-threaded code
without worrying over such niceties, but there are some latency-hiding
tricks one might be tempted to try with two closely-cooperating threads
(lots of stuff in the literature).

I think you're right, though the concept of "helper threads" isn't
new. In fact this is what prefetching hardware (and software
hinting) tries to do.

If the caches are shared, and the data is in the cache for CPU1, then CPU2
can most certainly access it. This is automatic and requires no special
programming. I get the impression that Myers wants to do special
programming to make it possible to share what's already available! Or am I
making a really dumb mistake? ;-)