Multicore Processing

[swaaye]

I have a question.

With dual CPU systems you don't get any advantages from the second CPU unless the program is coded to send threads to it. With multicore CPUs is this the same or is there some brainpower there that spreads it out automatically?

I'm sure we'll see developers quickly adopt multithreading for new stuff, but old stuff may actually end up running slower if recoding is necessary (it won't be done).

 

[3dilettante]

Mutlicores are independent processors on the same chip, so work is assigned to them the same way as it is to two or more physically separate chips.

With proper tuning, some software could take advantage of some reduced latency, I presume, but the general execution behavior would be the same.

If the multicore chips are clocked slower, then they will suffer in single-threaded performance compared to a single core that is clocked faster.

 

[Guden Oden]

With dual CPU systems you don't get any advantages from the second CPU unless the program is coded to send threads to it.

Well, if you're running several apps (even if they're single-threaded) you'll still see benefits. Like if you're running a media player with some graphic visualization while you're surfing the web, the OS will be able to balance the browser's CPU consumption on one CPU and the media player on the other CPU (assuming you have 2 CPUs in this case).

 

[trinibwoy]

Well, if you're running several apps (even if they're single-threaded) you'll still see benefits. Like if you're running a media player with some graphic visualization while you're surfing the web, the OS will be able to balance the browser's CPU consumption on one CPU and the media player on the other CPU (assuming you have 2 CPUs in this case).

Yep, you'll probably see some of the same benefits that are touted by Hyperthreading advocates.

I'm thinking that the single-core flavors will ramp in Mhz and be better gaming alternatives than their younger dual-core brothers for quite a while.

 

[T2k]

Mutlicores are independent processors on the same chip, so work is assigned to them the same way as it is to two or more physically separate chips.

With proper tuning, some software could take advantage of some reduced latency, I presume, but the general execution behavior would be the same.

If the multicore chips are clocked slower, then they will suffer in single-threaded performance compared to a single core that is clocked faster.

Actually it all depends... think: how about kernel-level execution?

 

[Guden Oden]

I'm thinking that the single-core flavors will ramp in Mhz and be better gaming alternatives than their younger dual-core brothers for quite a while.

However, most people use their computers for a variety of tasks I would think, so dual-core would be a huuuge benefit there. If only the P4 dual-core would have hyperthreading too, that'd be cool, but it seems Intel is disabling that feature. At least initially.

Probably to be re-introduced down the line as a premium feature. Still weird though, since they designed SSE3 specifically with instructions that boost hyperthreading performance...

 

[2senile]

I hope everybody will excuse my ignorance but I assumed there would be a layer so that a dual core CPU would be seen as a single CPU. If they require special coding the initial release of dual core CPUs will be a disaster when the reviews are published.

 

[MasterBaiter]

I hope everybody will excuse my ignorance but I assumed there would be a layer so that a dual core CPU would be seen as a single CPU. If they require special coding the initial release of dual core CPUs will be a disaster when the reviews are published.

I don't think there will be any special or optimized software out there besides the stuff which is already out there that takes advantage of dual processors. Games traditionally have performed poorly on dual processor systems in the past, so it will be interesting to see how this plays out. I think that coding games for dual core systems may be a bit of a challenge to boot. :?

 

[3dilettante]

I hope everybody will excuse my ignorance but I assumed there would be a layer so that a dual core CPU would be seen as a single CPU. If they require special coding the initial release of dual core CPUs will be a disaster when the reviews are published.

Dual or multi-core chips are composed of multiple identical cores, each of which individually is an independent processor.

The only difference between having a dual cpu rig and a dual core one is the distance between the two cores. The cores in a dual core chip operate exactly like they were on separate chips, just with some latencies involved with coherency greatly reduced.

Just like having two separate processors, there is some overhead and resource contention between the cores of a dual core processor. Everything else being equal, a dual core will usually perform slightly worse than a single-core version on single-threaded software.

On software that is able to spawn multiple computationally intensive threads, the multi-cores will be much faster.

 

[swaaye]

It sounds like it has limited applications, but where it excels it will be very welcome. 3D rendering, distributed computing (i want one for seti!), archiving maybe, encoding AV......

 

[olivier]

in some dual core desing (power 5) the two core share the same cache l2 and l3. so they use their cache more effiancy than a standard dual cpu.

 

[Tim]

in some dual core desing (power 5) the two core share the same cache l2 and l3. so they use their cache more effiancy than a standard dual cpu.

Neither dual core P4/Xeon nor dual core Opteron/A64 has any shared cache.

 

[jvd]

Well you can allways get the benfit in games of having the os and other tasks running on 1 core and the game itself running on the other .


But anyway i think it will be just like x86-64 .

It will come out as a buzz word then later on when there are enough cpus that feature it (2 or 3 years ) the first applications will take advantage of it .

 

[2senile]

Thanks to everybody for clearing that up for me.

I'm only interested in games, basically. The small amount of actual "work" I do (Office tasks, publisher, Photodraw etc) can be done to my satisfaction on either my XP or Win98 systems so I'd guess Dual core is not for me. Shame really, I was foolishly hoping it was a way to get around the little stumbling block there seems to be in increasing (overall) performance.

Well you can allways get the benfit in games of having the os and other tasks running on 1 core and the game itself running on the other .

How would that be done? Would it be that the OS grabs one core & assigns a game to the other core?

 

[3dilettante]

How would that be done? Would it be that the OS grabs one core & assigns a game to the other core?

Most often it's the OS that is in charge of thread scheduling, so a smart enough thread scheduler will try to put processing-intensive threads on different processors/cores.

This can be useful for a PC even without rendering or encoding something. If you have an anti-virus program that runs in the background, it might like to run intermittent scans that can cause disk access at random times. In other cases, disk access can be handled by one core while the OS remains responsive on the other.

Responsiveness is usually better in general if there is some thread that really likes to monopolize a processor for inconvenient amounts of time. It can monopolize a core and there will still be a free processor to keep the OS open for input.

I can't really say how often these things happen, or even if most casual users will even notice the occasional half-second pause. Dual cores really aren't justifiable given their cost for casual users in my opinion, at least not yet.

 

[pcchen]

I think one benefit for games is... well, the ability to do something in background while playing games
For example, I can schedule a TV recording in background, or transcode it into MPEG-2, and I can play games without problem.
For games to utilize multi-cores, well, I think it'll happen but I won't hold my breath. Current games already have too many bugs

 

[randycat99]

The way I've seen it work in practice is the OS will load-balance between 2 or more processors. So if you have a single process that is enough to conceivably swamp a single processor, you still would not see this by default. The OS would load twin CPU's at 50% each, which makes up the cumulative of 1 CPU of work. You can, however, manually pick a discrete process and assign it to a specific processor (my guess is to just let the OS schedule the way it likes, to take advantage of granularity, unless you have a very specific reason to assign to a single CPU). Then you would see one processor pegged at 100%. Programs designed to utilize multiple processors would be able to load both processors at greater than 50% each, naturally. Getting full 100% on both actually can be hard to achieve, as usually there are many other things that may get in the way of continuous full utilization conditions- waits for memory access, disk accesses, contention from other processes, etc.

Now isn't there an issue where local cache capacity is compromised somewhat since now the data for a particular process will reside in the local caches of both processors? So you have some memory wasted with duplicate entries and various states of revision. ...and a worst-case scenario is where you have a pending process waiting at one processor but the required piece of data happens to be on the other processors local cache. So you have a "few" clock cycles wasted while that data makes its way over. Potentially, this is where hyperthreading comes in handy to shove in something else to do while a pipeline is held up waiting for data that happens to not be local (as far as my layman's understanding of this stuff). So I guess this cache wastage issue is a potential reason to try assigning a process to a single processor. Naturally, cache management algorithms aren't exactly stupid either, and will be successful at masking these problems (less space wastage) in most cases. So you can't just assume you will get better cache performance for your process by binding it to a specific processor.

 

[3dilettante]

When it comes to caching, switching threads between cores excessively can cause more than wasted space.

If a thread is heavy in memory accesses, then it will force data for other threads out of the cache, hurting performance for those threads.

If it switches cpus, then there's a good chance that the data it brought in will be evicted, meaning it will bog down performance when it comes back.