There was a good article about a decade ago, "The Free Lunch Is Over" that you should probably read.

Moore's law, the observation that the number of transistors in an integrated circuit doubles about every two years, continues to hold true.

For 30 years or so that doubling was applied to a single processor. Programmers got a "free lunch" because the processors running their code became faster. You could design software that was more advanced than your hardware and be assured that by the time it launched the hardware would be able to handle it.

Starting about 15 years ago that "free lunch" began to end. Processor speed is still increasing but it is happening as a lateral change. Instead of having a single processor with improving performance, we have a growing number of processors with similar performance.

Parallel algorithms are harder to write, but can achieve both linear speedup and even superlinear speedup thanks to cache effects, accumulated memory, and other properties of parallel hardware.

The improvements in performance are still there, we just need to work harder to get them.

Considering my latest programs have been all bandwidth bound after optimizing them to fully take advantage of the cpu, I'm more interested in bandwidth gains, rather than cpu performance increase.
The world needs more bandwidth now, not more computing powerp

I think 'we are talking here aobout overall cpu performance not just

'computational without bandwidth' - I agree that bandvith (this is mov speed is most important)

EDIT

After all - what is the reason that movs cant be parallellised ?

for example if I would have such code

mov mem1, 0

mov mem2, 0

mov mem3, 0

mov mem4, 0

mov mem5, 0

mov mem6, 0

mov mem7, 0

mov mem8, 0

run in 'parrallel' it would be 8x bandwidth speedup but it doeas not work this way - it is a trouble with CPU or RAM-chip or what?

There was a good article about a decade ago, "The Free Lunch Is Over" that you should probably read.

Moore's law, the observation that the number of transistors in an integrated circuit doubles about every two years, continues to hold true.

For 30 years or so that doubling was applied to a single processor. Programmers got a "free lunch" because the processors running their code became faster. You could design software that was more advanced than your hardware and be assured that by the time it launched the hardware would be able to handle it.

Starting about 15 years ago that "free lunch" began to end. Processor speed is still increasing but it is happening as a lateral change. Instead of having a single processor with improving performance, we have a growing number of processors with similar performance.

Parallel algorithms are harder to write, but can achieve both linear speedup and even superlinear speedup thanks to cache effects, accumulated memory, and other properties of parallel hardware.

The improvements in performance are still there, we just need to work harder to get them.

It ended maybe not 15 years ago but maybe with pentium 4 and netburst architecture it ismaybe about 10 years ago (not sure but think that in 1998 it yet still goes further quick)

The trouble with many cores is that i think that you have no

general guarantee that every your code can be rewritten to

all the cores you wish and will gain such linear speedup (apart

from that that I still only see a 4 o 6 cores through all the years

and it is not very very big impressive)

I am not sure as to this guarantee but maybe some codes

are inherently limited to such many core rewriting and

paralellistaion - so there will be no speedup from cores at

all over soe limit to acheive)

The fundamental reason for CPU slowdown is interconnect speed (the delay through wires connecting two or more transistors). Two parts of a circuit path contribute to the delay of a circuit: transistor speed and wire speed. As processes scale down, the transistor continues to deliver faster and faster performance. Wires also benefit from this speed-up but at a slower rate proportional to the transistor.

Many reasons account for this difference. The distance between wires (wire pitch) must be large enough to avoid electro-magnetic cross talk -- the ability of a moving current to induce a magnetic field which modifies adjacent wires' magnetic fields and thereby their current. With enough noise, a downstream transistor might fire erratically. The common fix is to either space the wires further apart, because this effect is inversely proportional to wire separation distance, or insert a shielded wire between the two. Either way, you are now using up more space.

Even though the transistors are smaller, this extra wire spacing places them further apart (proportionally from prior technology versions) and slows their operational speed.

Also, wire pitch itself is worse off. At 20nm light diffraction patterns occur as in the classic double slit diffraction experiment. This is because device features are approaching the wavelength of light. Currently, fabrication plants use double patterning techniques to get diffraction patterns to overlap sufficiently. Double patterning places severe restrictions on VLSI design which affects transistor density.

Caching and memories have long had to deal with wire issues and it's the primary reason why they are slow -- a large capacitance is charged or drained over long wires (think RC time constants).

This is the main reason CPU designs have shifted to more parallel based designs. They can no longer reap the benefits of simple dimensional scaling.

Several stopgaps are being investigated: X-ray lithography (use X-rays instead of light to etch features because wavelength is much smaller). E-beam technology, where a stream of electrons does the etching. Most are far from production.

I predict someone will make carbon nanotubes a viable process or some such technology. When that happens you'll see one final discrete maximum frequency jump in CPU clock speed followed by very marginal gains thereafter.

I am interested in seeing how the ARM and x86 battle plays out. Will the x86 prefetch and decode hurt bandwidth too much? Is it insurmountable? Sure Intel may claim higher clock speeds, but it really doesn't matter if you take two clock cycles where a different architecture could do the same with a slightly slower clock but in one cycle.