More CORES vS more Ghz SPEED?

[ashetos]

The only problem with the 8GHz single core scenario is Operating System thread scheduling and context switch overhead.

If context switching was free and instantaneous, then the single core 8GHz core always wins.

 

[Roland00Address]

The only problem with the 8GHz single core scenario is Operating System thread scheduling and context switch overhead.

If context switching was free and instantaneous, then the single core 8GHz core always wins.

Nods

 

[toughtrasher]

If it was just me, I'd go for more cores. They have to at least be of decent speed though.

 

[Exophase]

The only problem with the 8GHz single core scenario is Operating System thread scheduling and context switch overhead.

If context switching was free and instantaneous, then the single core 8GHz core always wins.

That's also assuming you can scale main RAM bandwidth or latency with clock speed. And even then, multiple cores will increase opportunities for parallel requests to shared caches and memories.

And just so it's not overlooked, context switch overhead includes not just switching registers but also cache locality which is widened with multiple cores that each have local caches.

 

[ashetos]

That's also assuming you can scale main RAM bandwidth or latency with clock speed. And even then, multiple cores will increase opportunities for parallel requests to shared caches and memories.

And just so it's not overlooked, context switch overhead includes not just switching registers but also cache locality which is widened with multiple cores that each have local caches.

I don't agree that main RAM bandwidth is an issue, since the target is to achieve the same performance as the 4 2GHz cores, which will use the same exact memory subsystem to do the same work with 4 threads concurrently.

But of course, context switch overhead is like you said, much more than registers. TLB invalidation, cache flushes, thrashing etc. It's very expensive.

For high throughput applications, maybe the Operating System thread scheduling timeslice of about 10ms is enough to mitigate the context switch overhead (enough time to warm up various caches etc).

For latency sensitive applications though, it would be a disaster. Games are a perfect example. You can't afford to schedule one thread every 10 ms per game loop iteration if you want to target 60fps or higher. This probably explains why steamroller CPUs are unexpectedly good with 8 threaded game engines.

 

[Exophase]

I don't agree that main RAM bandwidth is an issue, since the target is to achieve the same performance as the 4 2GHz cores, which will use the same exact memory subsystem to do the same work with 4 threads concurrently.

On average over long enough periods of time, yes. But programs are often bandwidth limited only for short bursts. Multiple threads of the same program will often not be pegging bandwidth at the same time. It's similar to the matter of more memory request parallelism but not totally the same.

SMT and similar benefit in the same way, though.

 

[ashetos]

On average over long enough periods of time, yes. But programs are often bandwidth limited only for short bursts. Multiple threads of the same program will often not be pegging bandwidth at the same time. It's similar to the matter of more memory request parallelism but not totally the same.

SMT and similar benefit in the same way, though.

Right. You've got to stretch those memory prefetchers somehow.

A zero overhead context switching CPU (mythical creature) would be something like an practically infinite-way SMT core, and it would saturate the memory controllers.

I guess the takeaway of this discussion is, you'd like to use as many cores as the number of threads the programmer designed your program for, for optimal performance. And add some more cores for multi-tasking.

 

[Headfoot]

Though never in a hundred years will we see a publication dare to compare mobile to desktop offerings.

http://www.anandtech.com/show/7287/analyzing-the-price-of-mobility-desktops-vs-laptops/3

 

[zephyrprime]

Depends on the code. Some algorithms can only scale along the freq while some can be scaled with MOAR COARS...

Every algorithm scales with freq but only some scale with more cores. Also, even when they do scale with more cores, they have some overhead. For this reason, more freq is preferable to more cores. The only problem with more freq is that it is very difficult to get more freq out of processor nowadays due to the laws of physics.

 

[Denithor]

Drive-by trolling? OP seems to be MIA...

 

[tential]

Drive-by trolling? OP seems to be MIA...

Already said this in his other thread, you can look at his post history. He posts an inflamatory topic GENERALLY, then doesn't respond to it. Then a month later (not always just general), does the same thing again.

Last time he responded to his thread, He has asked "What are the best natural sounding headphones?
Then to respond to it he said he just wanted to ask, he wasn't purchasing anything.

None of it is against rules, it's just annoying when OPs don't even remotely care about the subject they're asking.

It's always in poor English as well.....

 

[sefsefsefsef]

Every algorithm scales with freq but only some scale with more cores. Also, even when they do scale with more cores, they have some overhead. For this reason, more freq is preferable to more cores. The only problem with more freq is that it is very difficult to get more freq out of processor nowadays due to the laws of physics.

High frequency is only good for programs with low Memory-level Parallelism:

http://en.wikipedia.org/wiki/Memory-level_parallelism

 

[Lorne]

So what about 8Ghz with dynamic HT.

 

[Roland00Address]

So what about 8Ghz with dynamic HT.

You still accrue a cost for the switching with hyperthread does not switch instantaneously but you will see a vast improvement. There is a reason why some versions of SMT work up to 12 threads per core.

 

[know of fence]

Though never in a hundred years will we see a publication dare to compare mobile to desktop offerings.

http://www.anandtech.com/show/7287/analyzing-the-price-of-mobility-desktops-vs-laptops/3

Thanks, well played. You caught my hyperbole, yet I hope at least some folks also caught my meaning: low TDP mobile offerings compare poorly, due to halved frequencies.
Also great find - a truly exceptional article.

 

[jihe]

I'm not seeing that at all. My gf's i3-4130 feels way slower than the 4.5GHz G3258 system I just put together. The pentium is smokin fast. To be clear, it feels faster than the i3 even when the pentium is running a full 2 core prime95 stress test. Yes it actually loads a 12 tab browser faster than the i3, even while the cores are jacked up to 100%. It's faster than my 3.3GHz i5-750 too, but that really isnt a surprise.

Your gf needs a fresh install or an SSD. Honestly I doubt you'll be able to feel anything given the same setups.

 

[n47h4n96]

Since you mentioned "mobile" if you are talking about processors in mobile phone devices, you have to remember a higher CPU clock results in higher temperature output. Therefore adding more cores than increasing the clock rate will offer more calculations to be processed whilst with a low clock rate for adequate temperatures