Difference between ''multi-core'' and ''multi-processor'' ?

As per the following, found in this website:

''All versions of Vista support multi-core chips and all versions of Vista ship with both 32 & 64 bit versions. Where the primary differences lie are in multi-processor support and access to RAM. We've prepared a handy chart below to help you compare the differences.''


For instance, is an Intel ''Core 2 duo'' only a multi-core or a ''multi-processor'' ? If only a multi-core, am I right to think that I would have no benefit to choose ULTIMATE, but remain with Home Premium?

Multi-core = Core2Duo, Core2Quad, AMD X2, etc. = multiple CPU cores in one physical CPU package

Multi-processor = more than one physical CPU package [requires motherboard with 2 or more CPU slots]; each of these separate physical CPUs could be a single-core, dual-core, quad-core, etc.

Thanks everyone.

Rob

ORIGINAL: droddey

Just to make sure it's clear though, from a performance perspective, there's no difference between a 2 core system and a system with 2 separate single processors. Well, if anything, the dual core system may perform better because of the higher level of integration of the caches and I/O of the two cores on the same die. There are just limitations in Windows OSes related to actual physical CPUs. They don't treat a multi-core CPU as two separate processors, so standard XP which will support two processors, can actually have 8 CPUs because you can put two quad core CPUs on the motherboard. XP only sees two physical CPUs in that case, but each one has 4 on-board CPUs. So you should be able to get stinkin fast performance out of basic XP with its two CPU support.

Then again, I could be completely wrong :-)

Actually, down at the gearhead level, there is a difference between multicore and multiprocessor, but for our purposes, they are almost equivalent.

As to which setup will give you better performance? I can't say for sure. There are both benefits and penalties in both schemes. You'd really have to measure the performance of both systems to know which is better. In the multi-processor system, each processor is the master of its own on-chip level 2 cache, while within the Core 2 Duo chip both processors must share (and wait for) the L2 cache. Given the same cache size, the Core 2 will run out of data faster than the single core processor and have to go off chip--point to the multi-processor system. On the other hand, managing bus contention between the 2 cpus of the multiprocessor system requires waits and computing cycles that are not a factor in the Core 2 system, as bus contention is done on chip in microcode--point to the Core 2 Duo system.

These aren't the only 2 factors. Until you actually test both systems under similar loads, you're just speculating on performance--it's complicated! Intel has performance comparison charts on their website, but I haven't yet looked at any of the Core 2 Duo data. You might find your answers there.

If I had to guess, I'd give the 2-processor system a slight edge in performance, but then again a 2 CPU system costs more, and has more parts that can fail, and requires more kernel level code to manage. These increased costs and potential support headaches just might overshadow a slight performance gain when considering other factors besides performance in your decision of what to buy.

If it were me I'd go for the Core 2 system, and that's just what I'm planning to do--buy a new Core 2 Duo system, perhaps in the next month or two after the 'back to school' sales work to push prices downward a few percentage points.

Hi Dean,

You could be correct. I don't think we know, and it is very complicated.

A quick look at Task Explorer tells me that Sonar (Studio) is running 21 threads and is using almost 1,600 files. Now, many of those are part of the UI and for the most part, are idle until somehow activated by the user.

Just think of all Sonar is doing when you're playing and tracking with a softsynth. It's capturing MIDI from an external keyboard, its sending that to the VST, at the same time reading the VST audio output and sending to the driver, perhaps after sending through an effect plugin or two. And maybe you're playing along with other recorded tracks--Sonar's managing that also. At the same time, Sonar's updating the display, maybe running a metronome. It's also saving to a MIDI file, and perhaps recording audio at the same time. All this is run in Windows time shared, demand paged virtual memory environment, which is also running dozens of other programs, monitoring about a dozen hardware interrupts, communicating with a network, and whatever else we require.

The mind boggles when you consider that all this passes through that L2 cache in some way.

There's another, smaller code cache closer to the processor that is organized as a series of "instruction pipelines" the Pentium uses to anticipate the program's next move. I works by lookahead, and when the Pentium sees a branch statement coming up in the instruction stream, it will try to compute both destination addresses, so no matter which branch is taken, the next instruction is ready for loading.

There's also a 'trace cache' in the P4 that keeps decoded instructions around for reuse--its like a little database of microcode that the processor can use for things is does over and over again, like applying the same operation on successive words, which is perfect for applying digital effects to audio data.

If you are fascinated by this stuff, there's a load of information on the Intel site.