Hello,
I am seeing a lot of marketing of Dual Core systems. As you have
guessed, I am not a hardware geek. What is the big advantage of dual
core systems? I know it is like having 2 processors. Will each core
perform at the high GigaHertz speeds that the marketers used in the past?
I plan to buy a new PC sometime early next year. Does the current
software technology take advantage of the dual core hardware? Is there
significant performance speed on the system?
Thank you in advance for any information.
Regards,
NJ

"Neil Jones" <castellan2004-gen@yahoo.comwrote in message
news:UfD7h.29335$gN4.21614@newsfe14.lga
Hello,

I am seeing a lot of marketing of Dual Core systems. As you have
guessed, I am not a hardware geek. What is the big advantage of dual
core systems? I know it is like having 2 processors. Will each core
perform at the high GigaHertz speeds that the marketers used in the past?

I plan to buy a new PC sometime early next year. Does the current
software technology take advantage of the dual core hardware? Is there
significant performance speed on the system?

Thank you in advance for any information.

Regards,
NJ

Each core runs at the speed they were designed, 2GHz, 2.2GHz etc
If an application is not written to take advantage of dual core tech then
a P4-3.2GHz will run that application faster than a dual core 2.4GHz
given equal archs. However if the application is written to be dual
core friendly then the 2.4GHz will beat the 3.2GHz single core machine.
Gamers are typically the ones who adopt speed tech faster than the
general public. Traditionaly games were single threaded but they are
being converted over to take advantage of multi core systems. Getting
more speed out of a single cpu by going multi core is easier at the
moment for cpu makers because of the speed wall they have just hit.
Eventually that speed wall will be overcome but until then putting more
and more cores in a cpu is an easier way to make them faster and faster.
There is another problem of scaling. Some system designs scale better
than others. When you add more and more cpu's/cores to a system
they all have to communicate together to get stuff done. That
communication takes time and resources which slows the system down.
A one cpu system works at X but a two cpu(core) system does not
work at 2X, it is more like 1.8X. You loose a little in the communication.
So a system with 80 cores in one cpu is not 80 times faster than a single
core cpu. "They" say that we will have 80 core systems in just a few years.
The Linux world has been multicore friendly for some time. The
Windows world is just catching up. Some apps like rendering and ai and
matrix math take full advantage of multicore while others like transaction
processing systems not so much. Mainframes have being multicpu/multi
core for decades. PeeCees are just catching up.

Now your next question will/should be what is virtualization? That's
another discussion.

If you don't want to be obsoleted for a while the current system to purchase
would be a dual cpu, dual core. hyperthreading, 64 bit system with
virtualization. So far one can get that in x86-64, Itanium, Sparc and
Power.
x86-64 seams to be winning for the moment because of price.

later,
charles

Sat, 18 Nov 2006 07:45:20 -0500, Neil Jones wrote:

Hello,

I am seeing a lot of marketing of Dual Core systems. As you have
guessed, I am not a hardware geek. What is the big advantage of dual
core systems? I know it is like having 2 processors. Will each core
perform at the high GigaHertz speeds that the marketers used in the past?

I plan to buy a new PC sometime early next year. Does the current
software technology take advantage of the dual core hardware? Is there
significant performance speed on the system?

Thank you in advance for any information.

Regards,

NJ

The others have done a good job of covering the technical aspects. Just
let me add that whether you will see any gain or not depends a lot on what
you do. I've read that a dual core processor does not real run as fast as
a two cpu system - it gives the equivalent of about 1.6 processors. If you
run a bunch of small jobs at the same time - you'd see an improvement. If
you typically run one cpu hungry job at a time and it is not written to be
multithreaded, then a dual core system will run no faster than a single
core of the same speed. Most processes are not written to be
multithreaded. for multiple processors is a very difficult
task.

work at 2X, it is more like 1.8X. You loose a little in the communication.
So a system with 80 cores in one cpu is not 80 times faster than a single
core cpu. "They" say that we will have 80 core systems in just a few years.

80X core would be a huge win for graphics on Linux since there is no
sight of open sourcing
of ATI and Nvidia graphics. It won't put high end gfx cards on the
shelf, but
it will probably blow the low end and midrange out of the water.
How affordable that performance would be in the long run remains to be
seen.
Nvidia and ATI are way ahead of Intel and it's probably way cheaper to
produce a
chip with 96 or 128 specialized lean and trim cores than fat x86 cores.
Maybe they can make X4000 based on their sucky ia64 :-]
Intel does not seem to be cutting corners and adding any questionable
code in their
2d/3d drivers to get a lead on the competitors. Hence X3000 being 2x
slower than 6200
that is ancient news in itself.
But I think in a long run Intel *will* put ATI and Nvidia out of
business if SGI
lawyers won't.

Sat, 18 Nov 2006 07:45:20 -0500, Neil Jones
<castellan2004-gen@yahoo.comwrote:

>Hello,
>
>I am seeing a lot of marketing of Dual Core systems. As you have
>guessed, I am not a hardware geek. What is the big advantage of dual
>core systems? I know it is like having 2 processors.

It's not just "like" having 2 processos, it IS having two processors.
Those two processors just happen to be on the same piece of silicon
(or two pieces of silicon packaged in one processor as in the case of
some Intel chips). The difference between having 2 processors on the
same silicon vs. two processors on the same physical processor chip
but on two separate silicon dies vs. two fully separate processors is
largely academic. than for determining how much money companies
like Microsoft, , IBM, etc. will charge for their software,
there really isn't much difference.

Will each core
>perform at the high GigaHertz speeds that the marketers used in the past?

Err, mostly yes. If you look around now you will see that modern
processors are no longer sold according to the clock speed (ie
GigaHertz). Intel and AMD have both found that clock speed alone is
not a very accurate way of describing the performance of a processor.
As such they have both switched to a model name and number scheme for
their processors. For example, Intel's current chips are sold as
something like "Intel Core 2 Duo 6600" or "Intel Pentium D 950", while
AMD has their "AMD Athlon64 X2 4600+" or "AMD 2212".

The different model names and numbers combined will tell you the clock
speed, the type of processor core, the amount of cache as well as
whether they are single core, dual core or quad-core processors.
other things get factored in as well, like bus speeds,
memory used or power consumption (power use has become rather
important in processors because it has skyrocketed in recent years.
Some of Intel's server chips consume more than 150 Watts in an area
not much bigger than a dime).

>I plan to buy a new PC sometime early next year. Does the current
>software technology take advantage of the dual core hardware? Is there
>significant performance speed on the system?

Given that there are well over a million pieces of software out there,
that's a pretty broad question! :)

There are really two parts to that question. First is whether or not
the System takes advantage of dual-core. The answer to that
is usually yes. Win2K, WinXP and Vista all do on the Microsoft side
of things, as do Linux and most of the BSDs. Windows 95, 98 and WinMe
do not and nor do a few of the obscure operating systems.

Now, S support is important because all modern Ses are multitasking
systems. This means that S can assign one task to one processor and
then stick another task on the second processor. This really is the
biggest and most immediate improvement from dual-core processors. The
computer is much better able to handle multiple tasks, and perhaps
most importantly, dual-core chips will give you a much more responsive
system.

Now, the second part of the question is the application side, and here
it's a bit trickier. You will often here the phrase "multithreaded"
thrown around here. This refers to an application that can split up
the work it's doing into 2 or more subtasks, or "threads". The
operating system can then send one thread to the first processor and
the second thread to the second processor, allowing both subtasks to
complete their work at the same time. Theoretically this could result
in an application doing things twice as fast if it can split the work
it does evenly between the two processors.

Unfortunately though, reality has to set in at some point. Splitting
tasks effectively between two workers is almost never 100% effective,
and sometimes isn't effective at all (just ask anyone who's tried to
manage two or more employees!). Some applications aren't written with
this in mind at all and others make only limited use of it.
still though do see HUGE improvements in dual-core systems. As such,
it's pretty much impossible to give a definitive answer to this.

In general, dual-core (and quad-core) chips are here to stay. They
are already the norm for servers, workstations and high-end desktops
and they are quickly moving down to the mid-range desktops and
laptops. They offer a BIG advantage right now in terms of
multitasking and responsiveness, while their impact on
single-application performance is growing. The retail price of AMD's
Athlon64 X2 line of dual-core processors now starts at about $150 for
the processor, which is pretty cheap. Full systems using this chip
start at about $600 and should be down under the $500 mark in about 6
months time.

Long story short: if you are buying a new computer, definitely get a
dual-core processor unless you absolutely can not afford one or have
some very specific need/reason not to.

Tony Hill
hilla <underscore20 <atyahoo <dotca

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

In article <pan.2006.11.18.16.47.33.167645@zianet.com>,
ray@zianet.com says
>Sat, 18 Nov 2006 07:45:20 -0500, Neil Jones wrote:
>>
>Hello,
>>
>I am seeing a lot of marketing of Dual Core systems. As you have
>guessed, I am not a hardware geek. What is the big advantage of dual
>core systems? I know it is like having 2 processors. Will each core
>perform at the high GigaHertz speeds that the marketers used in the past?
>>
>I plan to buy a new PC sometime early next year. Does the current
>software technology take advantage of the dual core hardware? Is there
>significant performance speed on the system?
>>
>Thank you in advance for any information.
>>
>Regards,
>>
>NJ
>>
>The others have done a good job of covering the technical aspects. Just
>let me add that whether you will see any gain or not depends a lot on what
>you do. I've read that a dual core processor does not real run as fast as
>a two cpu system - it gives the equivalent of about 1.6 processors.
>
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.

>
>If you
>run a bunch of small jobs at the same time - you'd see an improvement. If
>you typically run one cpu hungry job at a time and it is not written to be
>multithreaded, then a dual core system will run no faster than a single
>core of the same speed. Most processes are not written to be
>multithreaded. for multiple processors is a very difficult
>task.
>
Windows (and Linux) run many threads at a time. Dual cores will
help some in any case. With a dual processor/core system if one CPU
hog is running the system will still be responsive. A single CPU
system may be brought to its knees.

However, to get any benefit out of a dual core system, make sure it
has enough memory and fast disks (plural, preferable). If they get
in the way, the second processor is going to do nothing for
performance.

Sat, 18 Nov 2006 21:13:00 -0700, ray <ray@zianet.comwrote:

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?

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.

Sun, 19 Nov 2006 17:16:42 GMT, PdL <PdL@yahoo.comwrote:

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.

Butevery 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.

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.

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.

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" <krw@att.bizzzzwrote in message
news:MPG.1fcae68c3b0bb31989c00@news.individual.net
In article <1163971214.790271.219750@m73g2000cwd.googlegroups. com>,
rbmyersusa@gmail.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! am I
making a really dumb mistake? ;-)

In article <Gtp8h.1388$ql2.632@>,
fnsfmf@jps.net says
"krw" <krw@att.bizzzzwrote in message
news:MPG.1fcae68c3b0bb31989c00@news.individual.net
In article <1163971214.790271.219750@m73g2000cwd.googlegroups. com>,
rbmyersusa@gmail.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! am I
making a really dumb mistake? ;-)
>
>
>