A Bit Confused about Multi-Core Processing

[Luminal]

I have two questions that have been on the back of my mind for a while (I'm still using a single core computer... I'm a little behind the times):

 

1) When computer vendors (such as BestBuy, Gateway) use the term "Quad Core [model number], 2.40 GHz" does this imply that all four cores are 2.40 GHz or collectively? Such as: http://www.gateway.com/systems/series/529598059.php

 

2) When I program software, what do I need to do (if anything) to get my program to take advantage of multiple processors? If you're wondering, I use C++ in .NET (I also use other SDKs if that would be of any help).

[bascule]

1) When computer vendors (such as BestBuy, Gateway) use the term "Quad Core [model number], 2.40 GHz" does this imply that all four cores are 2.40 GHz or collectively? Such as: http://www.gateway.com/systems/series/529598059.php

 

Each core is running at a clock speed of 2.4GHz. It's not like they're each 600MHz and become 2.4GHz when you add them all together or something.

 

2) When I program software, what do I need to do (if anything) to get my program to take advantage of multiple processors? If you're wondering, I use C++ in .NET (I also use other SDKs if that would be of any help).

 

Threads are the standard answer, however using multithreaded programming to effectively leverage multi-core CPUs is difficult.

 

There are languages which try to solve this problem by providing better concurrency primitives than threads. Some examples are Erlang and Scala.

 

Scala is notable in that it can run on the .NET platform.

[Pangloss]

What Bascule said. It can be very tedious in the more common languages. Since you're working in .NET I recommend checking out the MSDN library articles on the System.Threading namespace. Also this article is pretty good on the basics:

http://www.c-sharpcorner.com/UploadFile/mmehta/Multithreading211162005044506AM/Multithreading2.aspx

[Luminal]

Each core is running at a clock speed of 2.4GHz. It's not like they're each 600MHz and become 2.4GHz when you add them all together or something.

 

So, in essence, it is a 9.6 GHz computer when running programs that can take full use of the multi-core nature?

 

 

Threads are the standard answer, however using multithreaded programming to effectively leverage multi-core CPUs is difficult.

 

There are languages which try to solve this problem by providing better concurrency primitives than threads. Some examples are Erlang and Scala.

 

Scala is notable in that it can run on the .NET platform.

 

What Bascule said. It can be very tedious in the more common languages. Since you're working in .NET I recommend checking out the MSDN library articles on the System.Threading namespace. Also this article is pretty good on the basics:

http://www.c-sharpcorner.com/UploadF...hreading2.aspx

 

Thank you.

[insane_alien]

no it is not the same as a 9.6GHz processor.

 

for one, a multicore would have much higher latency than the 9.6Ghz, but it would be able to run multiple apps faster as it reduces overhead by eliminating thread switching in the CPU.

[bascule]

So, in essence, it is a 9.6 GHz computer when running programs that can take full use of the multi-core nature?

 

Not quite for the reasons insane_alien stated...

 

However, the goal of Erlang is for your program to automagically run N times faster on N CPU cores.

[Pangloss]

One way to look at it is in terms of how efficiently we are using that growing store of fast-moving cache memory. We deal with slow main memory by stuffing as many instructions into cache memory as possible, so the CPU can do more during those 15-20 cycles it has before main memory is available again. Processors have stopped speeding up, but cache memory sizes continue to rise, and at some point someone realized that the cache could contain more information than the CPU could process in those 15-20 cycles. So they started throwing another core in there, just to make sure all those numbers get crunched before main memory wakes up again.

 

It's not a perfect explanation by any means, but that's essentially what's going on. That's why it's not like a "9.6 ghz computer", because no matter how many cores you stuff into that cache-ram-and-processors package, it can only process however much data you were able to shove into that cache in a given cycle. So in the end the computer is still (more or less) revolving around the speed of its main memory.

 

Also, as Bascule points out, how the code is written is a major factor on how efficiently this system runs. He could talk more about how Erlang addresses this, but I imagine that what it's doing is trying to be really efficient about what it shoves into the cache memory. (But please correct me if I'm wrong.)

[bascule]

Erlang's ability to run N times faster on N CPU cores is generally coupled with the idea that modern CPUs (including ones based on Intel's QuickConnect and AMD's HyperTransport interconnect) use a cache coherent interconnect to allow many caches and many memory controllers to be accessed by many CPU cores. This is effectively the NUMA approach pioneered by companies like SGI (i.e. one of those technologies like RISC that's been around forever but finally embraced universally by the mainstream).

 

When using a crossbar topology for the interconnect, the aggregate bandwidth scales exponentially with the number of CPUs, which is sufficient to prevent performance degradation. In other words, you can simply just keep adding cores and caches/memory controllers and the architecture will scale endlessly.