How do you compare single and dual cores power

This may have a painfully obvious answer but here's the question:

My previous understanding:
I thought that having a dual-core processor is sort of like having two separate "minds" to work on your computer's tasks. So a 2.0 ghz dual-core will let you do two really hard tasks simultaneously, like watch a video while burning a CD. But for any one program, you have a maximum of 2.0 ghz brought to bear.

Single-core PC's with "hyper threading" are designed to try to multi-task better, so you can do two easy tasks simultaneously. It won't work as well as a dual-core but it will be cheaper.

Quad cores are like dual cores but more so - more multitasking power, but for more money and heat output.

---

Crysis' system requirements are:

Quote:

CPU: Intel Pentium 4 2.8 GHz (3.2 GHz for Vista), Intel Core 2.0 GHz (2.2 GHz for Vista), AMD Athlon 2800+ (3200+ for Vista) or better

Now according to this, having a dual-core 2.0 Ghz allows your computer to do a task that would require a single-core 2.8 Ghz.

My question is, will 2.0 dual = 2.8 single for ALL applications, or only certain programs that are designed to take advantage of dual cores? Will 2.0 dual = XX single, where XX depends on the particular program? Is there some chart or formula you can use as a guide? And how do you compare quads to duals and singles?

It seems like within a year or two games will require 3.0 Ghz+. So will a 2.4 dual core handle that? A 2.8 dual? Do I have to go to a 3.0 dual to be on the safe side?

It's confusing. Thanks.

Jam it back in, in the dark.

Core clock rating these days is pretty much useless other than to compare a processor in the same line to another in the line. The reason is that there are a lot more factors than core clock rate. For example one core in a 2.0Ghz core duo is faster than a 3.2Ghz P4. There are many reasons for this which in include faster FSBs in the core duos allowing faster memory access which keeps the processor busy without stalling much. There is also much better branch prediction in the core duos and various other architecture improvements which allow better performance under lower clock speeds.

Unfortunately the move to dual core has made clock rating suggestions impossible. This 2.0 dual core = 2.8 single core is really just a huge amount of BS made up in attempts to resolve the issue at hand and really depends on the program itself. A well designed program can get nearly double the performance out of a dual core system than a single core system but a badly designed program might only see a 1% increase using two cores. And yes applications have to written to take advantage of dual cores. If they aren't then your application is running at 2.0ghz on one core, BUT other applications can run on the other core so there is still an advantage to a dual core system even if every application running is designed only for a single core.

The only rule of thumb I can provide right now is that the lowest clocked dual core is for the most part faster than the highest clocked single cores even when running on a single CPU meaning any dual core is going to be able to handle the requirements listed for a single core CPU. And a year from now I imaging single core clock speeds simply won't be listed on software. And again, there really isn't a general rule to be able to convert the clock speed of a single core to the overall clock speed of a dual core because that is completely dependent on the program itself and how it utilizes each core. Thats why most programs list single core requirements then dual core requirements separately.

There's nowhere I can't reach.

That's what I suspected and was afraid of. Thanks.

This thing is sticky, and I don't like it. I don't appreciate it.

What most users should keep in mind:

Not all tasks can be parallelized. That is a huge problem for multi-core systems, because with unparallelized tasks the second (and third, fourth, etc.) core is idling - resulting in no additional performance from your multi-core system.

Again this is no "it's hard to do" problem, but a fundamental problem. There are a lot of algorithms that are just not working with parallelization - this is mathematically proven.

And even if you can restructure your algorithm so it benefits from more cores it's always an additional burden on the programmer, because he has to control synchronization between the cores (of course only if the algorithms depends on that, but that's often the case).
Restructuring is a process that is currently done by hand, and which is very hard to efficiently automatize.

So don't think that multi-core architectures are the ultimate answer. They also introduce a lot of new problems.

I am a dolphin, do you want me on your body?

They're pretty sweet while compiling a program that you accidentally sent into an infinite loop, though. Or when I'm running a massive computational program that takes 10-20 minutes to calculate and I can still manage to get other things done on the computer while it's running.

I was speaking idiomatically.

@RacinReaver: The scheduler of your OS should take care of this. You don't need a multi-core system to have RT multitasking.
That's what process priorities are for. I usually set compiling jobs to lowest priority so they don't affect the overall system performance (and don't produce input lag).

Forcing applications to one core is only a good idea if the apps have problems with multi-core setups (the UT engine for example has some issues, resulting in too slow or too fast rendering).

What kind of toxic man-thing is happening now?