In fact, no CPU has ever done that. Only a small handful of instructions can be done in 1 clock cycle, most of them require 3 cycles, and some can require even up to 16 cycles. It really depends on the instruction in question. And this is all assuming the instruction and all the data it uses are already in L1 cache. EDIT: Thought that I should mention that RISC comes closer to executing instructions at 1 instruction per cycle than x86, but even there some exceptions do apply.

Not to mention that performance doesn't scale linearly with cores: most applications are still single-threaded and thus only run on a single core. A theoretical example would be compressing a large file with a really expensive compression method and the app doing the compressing was single-threaded: one of the cores would be at 100% workload, while the other one was simply waiting idly all the time. Thus it's simply wrong to say "it's got 2 1Ghz cores thus it's really 2Ghz!"

Even if the application was multi-threaded it still might not be able to use all the available cores to their full extent as it requires quite some expertise and knowledge from the programmer's part to know how to code everything in a way that causes no lock issues: if one thread on core #1 is waiting for some data the other thread on core #2 is still working on the #1 is still waiting idly by.