Hacker News Reader

Comment by pooriaazimi | Hacker News Reader

There's something I always wanted to know, but was too lazy to look up myself (I have a CS degree (or will, in a year) and have taken microprocessor, assembly, computer architecture and courses like that, but none of them talked about multi-core, so I don't know anything about them).

When you have lots of cores, I think your bottleneck would be cache and to a lesser degree, memory bandwidth. You can't have multiple cores manipulate the same memory address simultaneously.

Am I right?

View on HN

Spot-on. I came to post this. A CPU core != a Xeon Phi core != a GPU "core". Memory architecture matters a LOT, and much of CPU area is devoted to cache and memory infrastructure. In a GPU, my understanding is every ~32 cores share a small cache and MMU, which makes some SIMD operations / algorithms more challenging to implement. Good for some algorithms, not so great for others.

I think the whole focus on "cores" misses lots of issues. Memory infrastructure is only one. Instruction-level parallelism (superscalar & out-of-order) execution is another - even single-core processors like ye olde Pentium can execute multiple instructions per cycle. It's very easy and tempting to look at the number of cores and use that as a rough estimate of system performance. But this approach will land you WAY off of real-world figures. It's akin to using the number of cylinders in a car's engine to determine how fast it is - sure, to the first order, cylinder count is correlated with engine output and hence car speed, but it's only a very rough correlation.

For a recent example, google discussions about the CPU in the iPhone 5. It has two cores but a hugely improved memory bus. That makes it comparable in speed to some four-core phones at the same clock speed.

I'm wondering why you say that a 'CPU core' is different from a Xeon Phi core. I've looked a bit into the Xeon Phi microarchitecture and I don't see any fundamental differences (well, I guess it depends on how you define 'fundamental') compared to other processors.

You are somewhat right. You can't manipulate the _same_ memory address concurrently, but normally in multi-threaded programs your not doing that. Consider a traditional matrix multiplication program. You will pass each row/column pair to a core each pair occupying its own memory space ( or an address to a common memory pool that's read only), the core will perform the multiplication then it will pass that back to the parent to aggregate the result. The limiting factor in that situation is. Either the speed of the aggregating core ( you can sometimes parallelize that away by having multiple aggregation steps ) , or the amount of time it take to get all the data to the cores.

If you're doing lots of reads, the L1 and L2 caches help things a lot. They are an order of magnitude faster than main memory access, so as you add more cores, this helps in the overall performance.

The grandparent is right, the problem with multi-core is the L1 and L2 bottlenecking operations. The cache consistency protocols used to keep memory consistent between cores introduce more and more overhead as you introduce more cores. This is one of the reasons Intel's experimental SCC had no cache consistency. Eliminating cache consistency in multi core chips is the simplest way to eliminate the cache bottleneck.

I believe Larrabee was promising full coherency across all core caches.

Of course, many of us could have told them that that wasn't going to work, but they didn't ask us now did they? :-)

But then again, Xeon Phi which inherited some technology from Larrabee maintains cache coherency for its 60 cores.

Wow. At what costs?

I'm not trying to be dismissive, I'm just really interested to hear about the tradeoffs involved.

http://en.wikipedia.org/wiki/Amdahls_law

Which university are you studying at?

http://en.wikipedia.org/wiki/Amirkabir_University_of_Technol...

Reply on news.ycombinator.com