Have consumer CPU's stopped progressing?

I'm looking to upgrade my PC and the intel Q6600 looks like the best processor without going up into server pricing CPU's. This CPU has been out for over a year now, so surely it's time for another one at the same price and twice the speed?

What's going on?

GPU's are still progressing very well, as is memory and networking speeds, but CPU's seem to be coming to a stand still.

CPU speed has pretty much stalled. They are now focusing on getting more cores into each CPU.

Adding CPU cores looks like it will be the next step, but it's contrary to the nature of what a CPU is. I'm sure most programmers would prefer programming with a faster single-core CPU, rather than trying to program for more cores. Your applications for multithreaded apps are limited, and you have to be very careful with your implementation.

It will take another big jump, like the switch from vacuum tubes to silicon chips. Right now they are trying to add more vacuum tubes and hoping that will make up for their slowness.

You can get newer quad cores at very reasonable prices these days, even in local stores. The dual 9400's are faster than the old Q6600's at most games, so I imagine these quad 9400's are even better.

Here's a couple at the local Fry's Electronics this week, with mobos.

Intel Core 2 Quad Quad Core Processor Q9400 & ECS GF7050VT-M Motherboard $249.99

Intel Core 2 Quad Processor Q9400 & Intel Desktop PC DG35EC $329.99

They haven't stopped progressing at all.

Even though the chip has been out for some time, its current price is a fraction of what it was a year ago. (The quadcore Q6600 is little over half the price over what I paid for me dual core E6600 a year or so ago. The quad cores were significantly more expensive at that point in time.

There are plenty of chips that are faster than the Q6600 -- for example, there is the Core 2 Quad Q9650. The Q6600 is 2.4GHz with 2x4MB cache, and a bus speed of 1066 MHz. The Q9650 is 3GHz, has 12MB cache, and a bus speed of 1333MHz.
the price of the Q9650 isn't much different than what the Q6600 used to go for when they were new, IIRC.

25% speed increase, 50% L2 cache increase, 25% bus speed increase is hardly 'nothing'... you always pay a premium for getting the high-end chips.

Then there's also the Intel Core 2 Extreme QX9770 -- 3.2GHz, 12MB cache and an FSB of 1600MHz -- at a much higher price tag.

heh, I am still on a single 2ghz core at the mo :). Probably keep it another year or so unless something breaks. Will be interesting to see where PC tech is by that time.

heh, yep my main PC is athlon 1800, my laptops a little less, who needs more ?? Back on thread - Is it Moore's law thats becoming less of a law these days ?

I have a pentium 4, 1.7 Ghz, had it for about 6 years and still going strong! (A bit noisy perhaps, compared to more modern computers/cases which make almost no sound at all.)

Q6600 is a fine cpu, theres nothing really new until nehalem end of this year/early next year.

They've reached a physical limit, and 3.x GHz per core is about as fast as they can build them before they melt away. So CPU cores won't become much faster anymore, which is why they're adding more cores into a CPU and put more CPUs on motherboards.

Which in turn means that programmers -have- to find ways to take advantage of that paradigm shift. The time where you could write single-threaded/single-process-code and lay back and think "with next year's machines, this will be fast enough and nobody will complain anymore" are history. Next year's machines will have eight cores instead of four, or sixteen instead of eight, but the cores will run at pretty much the same speed at which they are running now. Nobody is going to revert that development.

Game over for performance hungry single-process/single-threaded software.

Not entirely true -- IIRC corectly AMD has also been researching the ability to have the CPU present itself as a single core and automagically break up the execution among multiple cores, which would appear to the OS as a CPU with less core than are physicially present, at a higher apparent speed than what the true cores are running at.

Not sure if that will ever see the light of day in a production chip or if it is even remotely effecient enough, but it's not completely off the table at this point in time.

There is a great deal of motivation to do exactly that. The point I was trying to make is from a development standpoint, multicore processing is a mess, and single-threaded technology should be used whenever possible. Developers aren't going to be able to utilize multicore processors as well as a single core. That means Intel can't sell processors to the public as easily. Which would you get more use out of, four 3.0 ghz cores or a single core 12 ghz processor? The only successful parallel processor to date is the GPU, and that works because the programmer doesn't really know it's parallel.

The multicore approach will come to an end as soon as the opportunity presents itself. However, this probably won't be for a while, maybe ten years, and in the meantime you should take advantage of extra cores in the few situations they are useful.

It certainly is easier to program a single core machine. The problem is that today's operating systems are launching so many processes just to provide a user interface, that it is more advantageous to have multiple CPUs to balance the work load.

The traditional game loop does not take advantage of multiple cores. But most of the applications that I use every day benefit from multi-threading and therefor are even faster on a multi-core system. I can max out all CPU cores easily when I process my RAW images in Aperture or convert videos. Even a stupid word processor takes advantage of multi-threading (background spell checking, for example). Most Internet software spawns worker threads so that the network I/O runs in the background. Spreadsheets and database software perform sorting in the background.

There's actually more software out there that benefits from multi-threading/multi-processing than there are applications where it does not help much.

It amazes me that game programming could evolve to today's level without taking advantage of multi-processing; after all, games simulate worlds, so there should be many things happening simultaneously. And yet, only few engines actually use it, and that not even very efficiently as it seems.

Isn't there a lot of research done on Quantum computers? And won't they even be more complicated to program than those "simple" multi-processor machines?

Anyway. Apple's Snow Leopard will come with a new API for multi-core machines that supposedly will make programming those machines easier. We'll see.

That research project that xlsior mentioned sounds interesting. But seeing that AMD is once again having a shaky ride, RD is usually the first department that experiences budget cuts.

I don't say that multi-threading is 'the' solution, and many folks argue strongly against using it, mostly for some very academic reasons that might not reflect the real life. But at least to my knowledge nobody is really arguing against multi-processing (with single-threaded processes).

By the way, this new Google browser does not use multiple threads, but it actually spawns multiple processes. It probably is more fun to use on a multi-core system. ;-)

Where's FlameDuck? This usually is his kind of discussion.

There are vacuum tubes in desktop processors???

>There are vacuum tubes in desktop processors???

Ahem, yeah, sure, why not!

lol.

Trying on his new hat, I think.

>Trying on his new hat, I think.

Yes, and it suits him too. It's a tinfoil fedora... Very snazzy!

A myth, often perpetuated by inexperienced (or simply poorly skilled) programmers. I've said it before, and I'll say it again (although apparently no-one is listening). Anyone who thinks concurrent programming is difficult, needs to stop using C++, and try Erlang or Stackless Python. Just for a week. Concurrent programming is only difficult because people insist on using a 36 year old programming language to do it, and Dennis Ritchie wasn't designing a language for multicore CPUs, primarily because they didn't exist at the time, and the idea that you needed 4 x 3.0 Ghz RISC cores to essentially replicate the functionality of a typewriter would have seemed preposterous.

The former (because you would have a factor 4 lower context switch frequency for starters, and in any decent RTOS (like say QNX) you could completely eliminate it for the other 3 cores). More cores is also cheaper.

Actually Superscalar CPUs (that is a CPU with more than one ALU/FPU) have been doing this since pretty much 1965. Every Superscalar CPU (which would be Pentiumish or something), even a single core one, is a parallel processor. Also considering that a 500Mhz GPU does pretty much everything several orders of magnitude better than a regular 3 Ghz CPU (particularly if you're using a Turing Complete instruction set), your "a 12Ghz CPU is better than 4 x 3GHz CPU" hypothesis seems rather shaky.

In C (or one of it's derived languages)? Yes, practically impossible. In Erlang (or any other modern language)? No.

Once for a dare, twice for a scare.

Great. Now I want one of those. Thanks a lot!

Okay, so it is due to programmers sucking. It doesn't matter if it is due to programmers being lousy, the result is still bad.

I thought they were testing optical processors that are supposed to be faster and more efficient than silicon based processors.

If they manage to get them done speeds should still start increasing.

>I thought they were testing optical processors that are supposed to be >
>faster and more efficient than silicon based processors.

Last I checked they haven't found a way to implement a transistor using light, so that's far off.

Generally i don't see multicore systems as a bad thing and they have quite some benefits in terms of scalability and by far lower costs. A big part of the problem comes from the software side and missing underlying concepts and layers which hide all this from you and just let you write your lines of code without thinking of how to split/parallise/synchronise things, not such an issue for the tasks which you can parallise easily but very annoying for the rest. It would be nice if there would show up some software concepts which lift you out of the 70s in the near future.

Well they have some, but the leading candidates have two major flaws.

1) They are too large to be useful.
2) They switch several orders of magnitude slower than a semiconductor, so any speed gained by light traveling faster than electrons is dwarfed by gate switching times.

Usually, when coding, if you're able to separate independent tasks on threads, you can make your applications a lot faster on multi-thread machines. I've noticed this a lot when making BLIde and I moved the code-analizer to a separate thread. Also some managed languages do run the GC on a separate thread, allowing complex GC operations, removing cicles, etc without compromising the application run speed. This architecture, wich is complex can make managed code almost as fast as unmanaged code on a single core. As this kind of GC removes unreferenced instances, mutex operations are, in most situations, not needed, so it works *fast*