The Future of Intel Processors

madison writes to mention coverage at ZDNet on the future of Intel technology. Multicore chips are their focus for the future, and researchers at the company are working on methods to adapt them for specific uses. The article cites an example were the majority of the cores are x86, with some accelerators and embedded graphics cores added on for added functionality. "Intel is also tinkering with ways to let multicore chips share caches, pools of memory embedded in processors for rapid data access. Cores on many dual- and quad-core chips on the market today share caches, but it's a somewhat manageable problem. "When you get to eight and 16 cores, it can get pretty complicated," Bautista said. The technology would prioritize operations. Early indications show that improved cache management could improve overall chip performance by 10 percent to 20 percent, according to Intel." madison also writes, "In another development news Intel has updated its Itanium roadmap to include a new chip dubbed 'Kittson' to follow the release of Poulson. That chip will be based on a new microarchitecture that provides higher levels of parallelism."

Comments

Interesting! Cell is making waves after all...

[seebs]

I think Cell's taught us two important things about heterogeneous multicore:
1. It's fairly hard to develop for.
2. It's bloody fast.

Looks like Intel's gonna be running with it some; that's good news for anyone making a living selling compilers! :) Buy stock in gcc...

Instead of more power

[nurb432]

How about more code efficiency? That would also improve overall security too.

If people coded properly, we wouldn't need this 'speed race' just to watch our word processors and browsers get slower and slower each release..

Re:Instead of more power

[CajunArson]

That would also improve overall security too.

I hate to break it to ya, but in a low-level language like C, doing proper bounds checks and data sanitization required for security does not help performance (although it doesn't harm it much either, and should of course always be done)
    There is a lot of bloated code out there, but the bad news for people who always post "just write better code!" is that the truly processor-intensive stuff (like image processing, 3D games) is already pretty well optimized to take advantage of modern hardware.
    There's also the definition of what "good code" actually is. I could write a parallelized sort algorithm that would be nowhere near as fast as a decent quicksort on modern hardware. However, on hardware from 10 years from now with a big number of cores, the parallelized algorithm would end up being faster. So which one is the 'good' code?
    As usual, real programming problems in the real world are too complex to be solved by 1-line Slashdot memes.

Re:Instead of more power

[fitten]

Define "bloat". For example, do you classify 'features', as in adding more of them, as bloat? I think the word "bloat" is thrown around so much that few people have a good definition of it anymore. For example, features (what lots of people call 'bloat') that aren't used *shouldn't* cause performance issues as the code for them isn't executed.

Besides, if we stopped adding features, we'd still be using things like ed for editing (and 'word processing'), our games would still be like Pong, and our remote access would still be VT52 terminals.

Re:Instead of more power

[morgan_greywolf]

Better code = less bloat = better performance and security.

The parent's point is that in code where it makes a difference, the code is already thoroughly optimized, in general. Slimming down the code for Microsoft Word or XEmacs or Firefox or Nautilus or iTunes (there, now we've slaugthered everyone's sacred cow!) isn't likely to make much of a difference because apps like these already run plenty fast on modern hardware. Sure, bloat is bad, but it's a lot harder to remove bloat from existing code without removing features than it sounds. If bloat is an issue, use an equivalent app with less features -- nano instead of XEmacs, for instance.

Re:Instead of more power

[Vellmont]

Better code = less bloat = better performance and security.

The thing you've failed to realize is that "bloat" is relative. One mans bloat is another mans "gotta-have-it" feature. Also the point of the poster was that "better performance" is a moving target.

Programmers don't design software for one guy, with one computer, that's run only next week. They design software for a hundred/thousand/million guys that runs on 200 different computers of different speeds, and for the next several years.

The basic takehome message here is that the computing world changes fast, and has a wide diversity of environment. "better" changes.

Re:Instead of more power

[nurb432]

The 'other mans' ( as you put it ) needs are not relevant.

Re:Instead of more power

[Nikker]

I think with all of these cores and such an increase in on die cache we should be asking what can we accomplish by staying on-die? As the number of cores increase so will on-die cache, when we start to get into 10MB+ area we could likely do some pretty fancy stuff, also treating registers as memory on idle cores will add to this. With all this micro-logic maybe even simple operations add + move ops will be added to the off-die ram as a type of pre-processing.

The more cores they add the more the system will seem to converge into the CPU, as this happens devices will become very simple as most of the system will be able to operate using a smaller package. As the system makes more money it will be come more and more closed, curiosity will lead to hacks, hacks will lead to other uses, which will give us an interface which will make the whole thing balloon up again....

What a tangled web we weave eh?

Re:Instead of more power

[Anonymous Coward]

your 3D games is an example of *totally* worthless code, regardless of the 'quality' )

Can I please attend your tea party? Or are you busy finding a boyfriend?

Re:Instead of more power

[Vexorian]

hmmm how about:?

Optimization = more specialized code = less maintainability = bugs are worse = adding features adds bloat = security issues

More powerful processors = less need for optimization

More powerful processors = Compilers take less time to do their job and developers get more time to work on their applications efficiently

Re:Instead of more power

[bberens]

I can't speak for the rest of those apps because I don't use them, but I can assure you that the javascript engine in firefox is pretty slow.

Re:Instead of more power

[drinkypoo]

your 3D games is an example of *totally* worthless code, regardless of the 'quality'

What does this mean? I like playing games, and entertainment is not worthless. I can only conclude (from reading and rereading your comment at least six times) that you disagree.

Re:Instead of more power

[ichigo 2.0]

For some reason javascript is slow on all browsers. I believe there is a W3C spec that mandates it.

Re:Instead of more power

[drinkypoo]

The 'other mans' ( as you put it ) needs are not relevant.

Well, as you are the only important person on the planet, I would like to know what you're planning to do about climate change.

Re:Instead of more power

[that this is not und]

If said 'features' balloon the size of the binary that has to be loaded, then it's 'bloat.' If said 'features' are shared in modules that get dragged into RAM for 'regular folks' tasks, then it's bloat.

If we stopped adding features, the base code would converge and improve to the point where it didn't need to be improved again, ever. But things like that scare the heck out of the marketing types, and the developers who work for them (basically, almost all developers.)

One of the big problems is that a major 'push bloat on the market' operator is Microsoft. One gets the idea they throw it all away and start over with every major version.

Re:Instead of more power

[that this is not und]

Perhaps the same thing that we did about 'The Population Bomb' back in about 1970.

Re:Instead of more power

[fitten]

One of the big problems is that a major 'push bloat on the market' operator is Microsoft. One gets the idea they throw it all away and start over with every major version.

I'd say that it's pretty much universal at this point. I can't name any reasonably modern system that isn't bloated.

If we stopped adding features, the base code would converge and improve to the point where it didn't need to be improved again, ever.

This statement must assume that we've solved every problem there is to solve. I don't believe that we have achieved that, yet (or maybe ever).

Multicore vs. implicit parallelism

[BritneySP2]

While multicores, obviously, have their use, the future belongs to CPUs with massive internal implicit parallelism, IMHO.

Re:Multicore vs. implicit parallelism

[twitchingbug]

What do you mean by implicit parallelism. I wikied it but that's at the software layer. Are you saying you should move that into the processor? What level of parallelism are we talking about here?

Re:Multicore vs. implicit parallelism

[MikShapi]

While CPUs with massive internal implicit parallelism, obviously, have their use, the future belongs to electric cars, IMHO.

Re:Multicore vs. implicit parallelism

[BritneySP2]

move that into the processor

In a manner of speaking, yes. For a compiler of a programming language to be able to implement the language's constructs efficiently, there must be an adequate support of those constructs by the target hardware.

On a more general note, the boundaries between hardware and software are always blurred, in that you cannot completely abstract one from another without hurting the performance of the system.

Re:Multicore vs. implicit parallelism

[BritneySP2]

Yours is a good point, if a bit obvious. Mine was to draw the attention to the tendency of talking more about multi-threading than making individual cores provide radically better support the implicit parallelism.

Re:Multicore vs. implicit parallelism

[MikShapi]

My point had to do with how silly making it look like an either-or scenario is.
Intel is very likely doing both with equal zeal, and the market is at a point where it will pay for useful advances in either.

Re:Multicore vs. implicit parallelism

[Anonymous Coward]

Yea, but can you actually say something that makes grammatical sense?

Re:Multicore vs. implicit parallelism

[BritneySP2]

There is some asymmetry to this. Speaking of cars, adding cores is, in a sense, like adding more wheels to a car. Simple; but there is an overhead; the performance increase is not proportional to the number of cores, etc. On the other hand, a car that is designed better may not need that many "wheels" anyway.

Re:Multicore vs. implicit parallelism

[Anonymous Coward]

My father works in Intel, he tells me they are going after expensive devices that are replaced quickly (like Cellphones today). Health-care will play a major role in this and I know Intel are pursuing a computer which draws blood, tests DNA for known diseases and then the 'contaminated' device is binned. The Idea is this is a total automated health check, and that they can volume sell it to hospitals and well I guess later on to individuals themselves.

Let's see where this takes us

[keithjr]

With process sizes getting smaller and smaller, it is interesting to watch new ideas for as to what to do with that newfound area. The elementary choice seemed to always be "throw on more cores" but the prospects of accelerators and bridges moving into Systems-on-Chips looks like it might have much nicer prospects.

The average parallism factor for most programs tends to hover around four. I think Intel might have figured out that this is a decent stopping point for hardware parallelism as well.

Re:Let's see where this takes us

[f00man]

In the early 1980's I was sure that Y2K would bring desktop machines with >10,000 (neural net) processors and paperless offices. I blame MS, Intel and HP.

I never really expected a flying car though.

Re:Let's see where this takes us

[smallfries]

The average parallism factor for most programs tends to hover around four. I think Intel might have figured out that this is a decent stopping point for hardware parallelism as well.

That's not really true anymore. The type of programs that we run has changed, and so the average has moved. Any of the media applications that I run regularly, or games has a much higher potential for parallism.

But gee

[MrNonchalant]

What I really want is a dialogue with Intel engineers about this piece of Intel-themed news. Why can't you add something like that to the site? You could call it something like Opinions With Intel or Intel And Opinions or Center for Intel. No that's not quite right.

Re:But gee

[Anonymous Coward]

Please sir, you need to take this quiz:
http://www.youthink.com/quiz.asp?action=take&quiz_ id=25577

Re:But gee

[CodeBuster]

Yes, but it would be even better if it included floating, animated, always on top rich media advertising that was triggered every time the mouse got anywhere near the opinion widget on the page. I just might turn off AdBlock to see it...or then again I might not.

This story should be posted 8 times

[Timesprout]

So we can can have comments in parallel.

Re:This story should be posted 8 times

[MyLongNickName]

Be patient. The other five articles should appear soon.

Re:This story should be posted 8 times

[Anonymous Coward]

Before anyone asks, the missing two were disabled to increase comment yield on the others.

Re:This story should be posted 8 times

[wbren]

So we can can have comments in parallel.

I think you ramped up your clock frequency too much. Your instructions are overlapping, causing data corruption in the pipeline and grammar mistakes. :-)

Re:This story should be posted 8 times

[MonoSynth]

...but subscribers can beat the rush!

Re:This story should be posted 8 times

[encoderer]

This is in reply to another thread where you mentioned "78% of all drivers consider themselves above average"

I couldn't reply there because I moderated in that thread.

Anyway..

I've heard others make fun of that. But people (you?) seem to overlook that it's entirely possible that 78% of people are, in fact, above average drivers. People (you?) often confuse "average" with "median."

I mean, it's simple: 1, 1, 2, 2, 2, 2, 2, 2, 2, 2 = average of 1.8. 80% are above average.

Re:This story should be posted 8 times

[MyLongNickName]

And if you read the thread you were responding to, you'd know that this has nothing to do with the "average" in question.

Re:This story should be posted 8 times

[encoderer]

it was an example. The point is that it's entirely possible that 78% of drivers _ARE_ above average....

Oblig.

[techpawn]

Who's going to need 80 Cores? *ducks*

Re:Oblig.

[WrongSizeGlass]

Who's going to need 80 Cores? *ducks* Any one wanting to run Areo on Vista Ultra Optimum Utmost Paramount Ultimate Quintessential Home Edition?

I, for one, am betting Intel loses its shirt on this 80 Core hodgepodge. That's why I'm investing my entire retirement saving in Transmeta's Crusoe line.

Re:Oblig.

[walt-sjc]

What would a duck do with 80 cores? Quack in harmony?

Re:Oblig.

[Anonymous Coward]

Probably those same assholes who wanted more that 640k of ram.

Bill Gates

Re:Oblig.

[Anonymous Coward]

Probably those same assholes who wanted more that 640k of ram.

Bill Gates yeah and for the same reasons, world domination

Cell and parallel processing. Answer this for me.

[zymano]

Why isn't parallel processing used more since more of us will need graphics/math intensive processors? We don't need faster word processors. The threading direction seems misguided to me. Is the state of parallel processing compilers not workable. I don't want to hear about the stupid '4 diggers to dig 1 ditch' analogy. Cliche.

gcc?

[everphilski]

Buy stock in gcc..

Yeah, cause, you know, Intel doesn't make their own http://www.intel.com/cd/software/products/asmo-na/ eng/compilers/284132.htm">compiler...

Re:gcc?

[walt-sjc]

It's a joke son. Gcc is GPLed.

Re:gcc?

[seebs]

You know, come to think of it, IBM has a compiler too.

Maybe, uhm... A joke?

(That said, stuff like this IS good news for anyone working on gcc professionally, potentially, although it does have the short-term impact of creating a class of apps where gcc isn't going to be as good as the industrial and research compilers for a while.)

Re:gcc?

[stephentyrone]

it does have the short-term impact of creating a class of apps where gcc isn't going to be as good as the industrial and research compilers That class already exists, and the impact isn't short-term. Sorry, gcc is quite good, but it's not as good as the industrial and research compilers on anything more complex than hello world.

Note that I use gcc regularly, and I believe it to be "good enough" in the vast majority of cases. But from a performance standpoint, it still has a long way to go.

Re:Cell and parallel processing. Answer this for m

[keithjr]

Well, the analogy I've always heard was "1 woman can have 1 baby in 9 months, but 9 women can't have 1 baby in 1 month." Lesson here: not everything is as "parallelizable" as digging a ditch. Data dependency in single execution threads means there often simply isn't enough independent work that can be done at once. Moreover, it is often left up to the user (or third party vendors) to create the application library to take advantage of parallel processing. Almost all code being run at this moment was writen in a serial, higher-level language (such as C++) for serial execution (even if it utilizes threading in the OS). The Cell didn't provide a very good API, and even trivially parallelizable algorithms often have to be rewritten in assembly code to take full advantage of the available hardware. And that just plain sucks.

For the long term

[ClosedSource]

Intel needs to develop new processor technologies to significantly increase native performance rather than just adding more cores. Whether multi-core processors can significantly increase performance for standard applications hasn't yet been proven and even if possible, will depend on the willingness of developers to do the extra work to make it happen.

If software developers can't or won't take advantage of the potential benefits of multi-core, Intel and AMD may have to significantly cut the price of their processors because upgrading won't add much value.

Re:For the long term

[timeOday]

Intel needs to develop new processor technologies to significantly increase native performance rather than just adding more cores.

Figure out how to do that and you will be a rich man. The move to multi-core is a white flag of surrender in the battle against the laws of physics to make a faster processor, no doubt about it. The industry did not bite the bullet of parallelism by choice.

Re:For the long term

[0xABADC0DA]

That sounds like what they are doing, improving performance by making more things native.

For example, they could put a Java bytecode interpreter "cpu" into the system. Java CPUs didn't take off because a mainstream processor would always have better process and funding, and you had to totally switch to Java. But if everybody had a Java "cpu" that only cost $0.25 extra to put in the chip and got faster as the main CPU got faster, then it might actually be useful (incidentally .NET bytecode is too complicated to run directly in a cpu).

Alternatively, they could put in generic garbage collection as a separate processor that runs all the time. This could accelerate Python, Java, .net, perl, ruby, smalltalk, and any number of other 'slow' languages that people are using anyway. The can add in a cell-like cpu who's only purpose is lzw-style compression or hashes, or these could be just *really* slow uninterruptible instructions only available on some cores... leaving others to handle interrupts and whatnot.

I don't think multi-threaded code is necessarily the only way to take advantage of multiple cores.

Re:For the long term

[DNeoMatrix]

I think what we need are (STANDARD) commands to say, how many cores? okay - throw this thread on core A, this thread on core B, and let me handle the interlinks, from a programming end. I know you can probably do this in ASM or with interrupts, and probably from C - but it's really got to get a lot more straightforward. Once it's as easy as speaking it, then it will be more likely that an average programmer will use that mechanism, and thus programs as a whole will begin to pick up enormous pace, and they will be able to adapt, at RUN TIME to the running conditions.

Re:For the long term

[the_lesser_gatsby]

It's already pretty trivial in Java to write multi-threaded code, but the last thing you want is to have to specify which cpu to run individual threads on as you suggest. Just let the scheduler decide where to run the threads, then you will get adapt to runtime conditions.

Re:For the long term

[DNeoMatrix]

maybe, but maybe not, sometimes the control can really help out. Especially if there are commands to find out which cpu things are already running on, especially in the area of non-unified caches. Let's say you have three threads, all of "equal priority" on a system with two cores. So in general you can add them in any order and they work either way. But say one of your threads is controling the other two by human input, while one is modifying data and the other is analyzing that same data. If you have those two on a processor together, and the control program on the separate core, you can have much faster memory access (depending on your access patterns) because they are both running with the same cache. But if you had them on separate cores with the control thread on a random one, the actual threads may get more run time, but it will also take much longer to access the shared memory, since the caches must be kept in sync, writing through all the way down to a unified level before being brought back up to the core's personal cache for use in the other thread. I'd rather do a couple extra micro-seconds ops waiting to switch threads, rather than have to go through the process of copying cache data. And while we are making headway in unified caches, that's still only L2 caches, there will always be a small portion of cache that is not unified. And it would still be nice to have this level of control in a program. Any besides - we're not supposed to say "It's easy in java so let's just let the scheduler handle it" - we're supposed to say "I want to control every aspect of my computer", and the speed you loose by using java is not worth the simplicity of Java threads. Though I will admit - I do really love the way Java works. especially with threads, exceptions, and GUI (swing). Not to say I'm right... maybe I can never be satisfied with the options I'm given - I always want more and more control, I should just write a kernel - hahaha.

Re:For the long term

[Chandon Seldon]

Concurrent programming isn't really that hard a problem. To do it easily using todays tools requires some "design patterns" that many programmers aren't used to, but the concurrent models actually end up being cleaner / more intuitive than the serial model in many cases (including things like network programming and GUI programming).

The problem is that the tools don't make these patterns blindly easy, and they require a little bit of programmer discipline to use properly. That occasionally includes giving up minor performance advantages for code cleanliness - think of it like the "don't use gotos" rule in structured programming.

The simplest view into the method of concurrent programming that I'm talking about is here: http://video.google.com/videoplay?docid=8102320126 17965344

That doesn't solve the general "number crunching" problem - for that you need parallel algorithms - but that's been solved in scientific computing clusters for decades.

Re:For the long term

[Overly Critical Guy]

Intel needs to develop new processor technologies to significantly increase native performance rather than just adding more cores.

I'm sure they would have done that already if they could. The problem with more powerful processors is the amount of power they use. By using multiple cores of slightly less powerful chips, you get more performance with less power usage.

Re:For the long term

[Vellmont]

I think this is this most intelligent reply I've heard about multi-core processors. Everything I've heard up to this point is the standard "But multi-threaded programming is both hard, and has diminishing returns". Which is very true. I've often wondered how the hell I'd break my programs into 80 different independent parts.

Ultimately I think you're right. Processors started out general, and have become increasingly specialized. First we had the "floating point co-processor", next stuff like an MMU, then GPUs came along. Multiple cored with differing functions is in many ways just a continuation of that trend.

Re:For the long term

[ClosedSource]

I don't make any claims about how hard concurrent programming is supposed to be, but until we see a lot more real-world apps running on multiple cores, we won't know how much of a performance gain will be seen. I'd say anything less than a average improvement of 25% wouldn't justify rewriting a legacy app to accomodate multiple cores.

Re:For the long term

[Chandon Seldon]

until we see a lot more real-world apps running on multiple cores, we won't know how much of a performance gain will be seen.

You can estimate that sort of thing reasonably well. A lot of things parallelize in some really obvious way - enough that you'll get better than twice the throughput if you move from one to four cores. Other things would gain a perceived performance advantage simply by using a concurrent programming model even on a single core - tabbed web browsers with plugins / javascript are a good example.

I'd say anything less than a average improvement of 25% wouldn't justify rewriting a legacy app to accommodate multiple cores.

Only some few really obnoxious cases like finite state machines can't be parallelized for a >25% performance gain. And even for those cases, it frequently turns out that you want to run more than one of them in parallel anyway.

Re:For the long term

[robbot]

Anandtech had an article about this very thing, regarding AMD's torrenza. AMD - The Road Ahead

Re:For the long term

[ClosedSource]

"I'm sure they would have done that already if they could."

I'm sure prior to the invention of the Integrated Circuit, many hardware engineers thought that computers couldn't be made any smaller than a large closet. The technologies used today for creating processors are essentially refinements of the IC technology created in the late 1950's.

I'm not suggesting that Intel and AMD have a lot of options based on that legacy technology, but the future belongs to the companies that can develop new technologies. These new technologies may be developed through research into ideas like DNA computers, Quantum computers, or chemical computers etc. Or they may be based on new ideas that nobody has thought of yet.

I find it hightly unlikely that multi-core software techniques will be able to sustain significant performance improvements for more than 10 years, if that. Of course the same physical laws that restrict the performance of single core processors will significantly limit the number of cores that can be integrated in a single chip, so multicore hardware isn't going to scale very far either.

Re:For the long term

[ClosedSource]

I suspect that in the real world of applications running concurrently with other applications, these estimates may not hold up very well, but let's see what the next 5 years bring.

Re:For the long term

[Anonymous Coward]

Central garbage collection is a pretty decent idea, and is usable by a wide range of programming languages and styles, since the major restriction is in the expectation that the (numerical) value of a pointer is constant, and that a pointer can be type-punned from another fundamental data type.

In C terms this means that:

void *v; uint64_t u;

Given an assignment v = then v will always point to u and *v == u always, but
Given an assignment u = (uint64_t) v; then ANY subsequent test u == &v may fail.

Likewise, v = (void *) u; may fail or produce unexpected results immediately or upon dereference of v.

A smart approach would be to have the GC "firmware" leave behind broken heart relocation symbols for runtime environments to react to, so that in the two failure cases above, the pointer itself can be updated to the relocation address. This is usual behaviour for a copying GC.

There are threaded GCs available now which use either read or write barriers (or both) plus broken heart relocations in order to run GC in a separate thread. The only synchronization point is changes to the "new" cell pointer, which is simply tested for overflow and incremented for each allocation, and reset when collection on a retiring semispace is begun due to overflow.

There has been some research on large globally-shared managed heaps, but most are not accomodative of a POSIX-like process model. There is no reason that hardware could not perform collection on multiple GCed heaps (one or more per process), however. Hardware may also be able to better manage multi-flavoured managed heaps -- a copying GC (generational model, for example) a swept GC (no relocations, first or best fit allocations into free and freed space), and a one-shot-in-local-address-space GC (no relocations, and no reuse of freed space (but freed space occupies no real memory or backing store)). Each of these has advantages and disadvantages with respect to locality of reference, coherency, and different allocation-time costs.

Moreover, GC parallelizes well when there are multiple roots from which to trace object liveness, so hardware for multiple managed heaps is attractive in that respect as well. Interactions between the tracing and backing store are likely to be complicated, however, especially in edge cases. For example, tracing liveness of rarely used objects on a machine with lots of demand paging out to disk is likely to result in increased demand paging activity, however the generational hypothesis suggests that this would be fairly rare.

One obvious shortcoming is that liveness semantics for non-automatic variables in C and its descendants are ugly, and these are popular languages one would presumably want to support with collection but without a major software porting requirement.

Clock Speed?

[tji]

It seems that Intel very rarely mentions clock speed in any of their roadmap briefings. The clock speed increases over the last five years or so have been pretty minimal. Moore's law talks about the rate transistor density increases. But, clock speed has followed a similar curve until recently. The last 4-5 years has to be the longest plateau in the history of the industry.

Yes, I know they changed to a new architecture that put less emphasis on raw clock speed. But, given that more efficient architecture, clock speed increases are still going to be a major benefit.

So, what's the story? Has the industry hit a wall? How long will it take to get back to above 3GHz for a mainstream processor, or even to the 4GHz levels that the old Pentium IVs were pushing.

Don't get me wrong, I am a huge fan of the power efficiencies of the new chips. For my primary purposes (laptop, HTPC) the new chips are a godsend. And, the thought of specialized "accelerator" cores is fantastic (a video decoder core for MPEG2 & H.264, please). But, doing that same thing at 4GHz is even more compelling (of course, with the speedstep++ stuff to shut down cores when not needed, and throttle back to low GHz to save power).

Re:Clock Speed?

[ZachPruckowski]

Penryn (a die shrink of the Core2 Duo/Quad plus some SSE4) should have 3 GHz+ models. The real performance issue isn't clockspeed, it's instructions per second. When you make 128-bit SSE take fewer cycles, and you add execution units, improve scheduling logic, and reduce access latencies (through pre-fetching or larger caches, or faster buses), you make processors faster. A processor that runs at 2 GHz with 3 Instructions per clock is just as fast as one that runs at 4 GHz with 1.5 IPC. The reason clockspeed hasn't been increasing is because performance gains have been coming from other areas. Intel could probably sell a juiced-up 3.6 GHz Core 2 Extreme, but it'd run at 180 Watts or something, and cost like $1500.

Re:Clock Speed?

[timeOday]

The real performance issue isn't clockspeed, it's instructions per second.

Bull. The fact is, the MHz "myth" is mostly true. The vast majority of improvement in processor speed over the past 30 years is due to clock rate, not IPC. The performance gains from other areas over the last 5 years have not kept pace with the rate of progress for the preceeding 25 years, not even close.

Re:Clock Speed?

[644bd346996]

Sure, for most of the past 25 years, it has been the clock speed that's been improving. But that's changed in recent years. When Intel switched from Prescott to Core, they pretty much cut the clock speed in half without really sacrificing performance. That's because they increased the IPC a lot in Core, so that it had comparable IPS.

When comparing different processors with the same ISA (ie x86), IPS is the best measure of CPU performance, not clock speed.

Re:Clock Speed?

[Vancorps]

Tell that to the Amiga guys and to AMD when they chose IPC over clock while the P4 was around. Both are very important. The industry spent years ramping up the clock and now they're spending a few years working on IPC. It makes perfect sense to me. Moore's law also doesn't refer to the frequency of a chip but to the number of transistors which has kept pace especially now with the 45nm processes.

Personally I think for the moment IPC is far more important than frequency given computers are doing more and more these days not just doing one thing faster.

Re:Clock Speed?

[raftpeople]

Has the industry hit a wall? How long will it take to get back to above 3GHz for a mainstream processor

Power6 is a mainstream server processor operating at 4.7ghz in servers today, and at 6ghz in the lab. While it's clear that gains are more difficult now, it would appear the industry has not hit the wall yet.

Re:Clock Speed?

[Sinical]

Look for POWER 6: 4.7GHZ.
Look for bumps in Cell or Cell2: Cell2 expected @ > 4GHz.

Note that these will go into machines where more expensive heat dissipation devices can be used, i.e. any of IBM's machine or RoadRunner.

Re:Clock Speed?

[timeOday]

Tell that to the Amiga guys and to AMD when they chose IPC over clock while the P4 was around. Both are very important.

Not equally important. The original 8086 ran at 4 mhz and had an average CPI (in actual use) of 12. The Core 2 has a theoretical maximum of 4 IPC. That's only a difference of at most 48 times (actually less, but I couldn't find benchmark IPC data for Core 2). Meanwhile MHz over the same time period has increased by a factor of greater than 500! Thus 90% of the difference is from good old MHz, not IPC. IPC is simply not going to increase to 40.

Re:Clock Speed?

[Doctor Faustus]

So, what's the story? Has the industry hit a wall?
Yes. There was a big story about three years ago that when Intel got its first chips from some new process shrink (90 nm?), they were startled to find that they couldn't get them to run substantially faster than the previous version. Up until then, they'd always gotten a significant speedup from that with no design changes, but they did hit some sort of physical limit no one was expecting. I haven't heard anything since about whether they figured out what it was.

Basically immediately, the Pentium 4 line was ended, and they started planning to go back to the Pentium 3 design (P-6 architecture, introduced in 1995 on the Pentium Pro), which had been quietly improving as the Pentium M in the meantime.

even to the 4GHz levels that the old Pentium IVs were pushing
The Pentium IV had a couple of really good ideas ("trace cache", off the top of my head -- the instruction cache was post-decode), but it was fundamentally a really dumb design. It was optimized for a clock speed number they could put on a label, even though it degraded performance by taking pipelining too far. It was really fast if you could keep the pipeline full, but the only common application that could do so was video encoding.

Re:Clock Speed?

[ZachPruckowski]

Instructions per Second = Cycles/Second (the MHz) * Instructions/Cycle (IPC). An IPS increase can come from either MHz or IPC increases. Therefore, if you triple IPC and halve MHz, you have a 1.5 increase in (single-threaded) performance. You misread "instructions per second" as IPC, which it isn't.

Re:Cell and parallel processing. Answer this for m

[LWATCDR]

Okay how is threading not parallel processing?
One of the great difficulties of the Cell is asymmetrical in nature. With a Cell you have to do a lot more resource management than with symmetrical multiprocessor system. I have not worked with the Cell but some of the issues I could see cropping up is that it maybe a little light in none floating point resources. With only one PPC core there may be issues with keeping all the SPEs busy.
The 360 is no slouch when it comes to floating point but has a lot more general purpose CPU power than the PS3. The PS3 will kill the 360 in things like transcoding video but the 360 maybe a better mix of capabilities than the PS3.

New term war.

[jshriverWVU]

I was just checking out this page here which discussed a machine with 768 cores. While I do a good amount of parallel programming this is good news to me. But it seems for the average person, this is turning into another mhz/ghz war, this time cores.

What we really need is for software to catch up. Luckily some programs like Premiere, Photoshop have supported multiple CPU's for a while now. But games, etc can really benefit from this. Just stick AI on 1 core, terrain on another, etc etc.

Re:New term war.

[MikShapi]

"Software" (as in all software ever written) is not a monolithic thing. The vast majority of software in use today is not CPU-restricted by modern (and even 5-year-old) commodity hardware.

Of the little bit that does need oompf, Where SMP can be taken advantage of, people have largely been working on doing so for a while now.

Only the little fraction that remains - projects that CAN USE the extra oompf and haven't been developed in that direction yet - need to catch up.

Your statement hardly applies to most software out there.

Re:New term war.

[suggsjc]

First, I'm not saying your wrong. But the (processor) world doesn't revolve around /. comments/criticisms. Meaning, its all to easy to look at companies (esp big companies) and say that they just get going in one direction and don't stray from the course until it hits a dead end.

Do you really think companies will intentionally go in the wrong direction (more GHz, more cores, etc) just because? Possibly for marketing reasons, but outside that I would think that with their massive R&D budget that they would be exploring other ideas to give them the edge over the competition. Yes, sometimes it takes a new-comer to shake things up, but at the same time the big companies are pushing as hard as they can to either get an edge or narrow the gap...so give credit where credit is due and stop complaining (not that you were necessarily complaining, but almost any tech war cores, ghz is going to result in better tech for the consumer).

Re:New term war.

[Anonymous Coward]

What people often fail to understand about that "GHz war" is that the problem is not that Intel and AMD pursued high clock speeds, but that they were sacrificing other factors. The Pentium 4's high clock speeds were attained by using a very long pipeline, resulting in various drawbacks like a long flush / warm-up phase.

I don't think that's the case now - I'm sure there has been some small sacrifices to accommodate the large number of cores, but not that great. Furthermore, unlike the GHz war, the focus is about scalability- so the overhead for operating 4 cores would not be very large compared with 8 cores.

I think the industry is going in a very good direction, especially with the concept of specialized cores.

Re:New term war.

[vecctor]

But games, etc can really benefit from this. Just stick AI on 1 core, terrain on another, etc etc. Indeed. I know Supreme Commander actually does this - and they recommend multi-core processors. I believe they said it uses up to 4 cores.

Re:New term war.

[Bat Country]

Not all tasks are created equal. Ignoring completely the synchronization problems inherent in multithreading, the fact is you'll have cores lying idle instead of doing their share simply because the thread you've thrown on there doesn't have enough work to do.

Bearing in mind that I've never had to do anything other than throw physics and graphics on one thread and AI and input processing in another, I've found even that to be a huge pain in the ass for synchronization and keeping everything busy and balanced.

When we're dealing with huge amounts of somewhat weak individual cores, just splitting the program into four or five discrete threads is probably a terrible idea for parallelizing a game.

Ideally for a massively multi-core system like the new processors, you'd have the individual subsystems of the game dump discrete work units or jobs into a queue. These would have to be atomic work units - small bite sized tasks which should be doable in a fixed timeframe - like processing a single AI cycle for a single AI actor, performing collision detection in a single volume, updating the positions of graphical elements, etc.

All of this work would get unloaded from the work queue by a few threads of dispatchers which would check for locks on the required resources, push it back in the queue if the resources the task needed were locked, and otherwise throw the task onto its own thread with a callback to unlock itself when it is done.

Following behind those workers would be a cleanup thread whose job it is to make sure that each of the tasks which hasn't phoned in as complete in a timely fashion isn't locked up doing something and has properly unlocked all of its resources.

Figuring out how to atomize tasks which have traditionally been extremely linear or recursive is going to be a serious challenge for game programmers.

While an application like Photoshop can just split up an image into different regions and process each part of those, some tasks just don't divide that well.

Parallelizing collision detection for instance is most likely a complete nightmare - imagine trying to decide how to split up objects so that all possible collisions take place in the same space, and yet still split up the space into equal sized units without ignoring any potential intersections.

Basically, games aren't a special case - like all other programming applications, learning to parallelize is not going to be easy for a generation of people growing up linear or OO.

Re:New term war.

[kramulous]

But games, etc can really benefit from this. Just stick AI on 1 core, terrain on another, etc etc.

I don't develop games at all, but wouldn't that introduce a disk IO problem? Unless you had a monolith (perhaps polylith?) of system memory, the bottleneck will be the hard disks.

Re:New term war.

[kramulous]

Parallelizing collision detection for instance is most likely a complete nightmare - imagine trying to decide how to split up objects so that all possible collisions take place in the same space, and yet still split up the space into equal sized units without ignoring any potential intersections.

Use token ring parallelism for this task. Block parallelism does not bode well for this type of interdependency.

Improved cash management

[gEvil (beta)]

I've found that improved cash management does wonders for me, like allowing me to buy things like new processors.

Remaining Interchangable

[Nom du Keyboard]

My thought is: How long can Intel and AMD remain interchangeable? For that matter, how interchangeable will Intel be in the same socket, if processors are going to vary this widely? In is this a good thing?

Re:Remaining Interchangable

[drinkypoo]

For that matter, how interchangeable will Intel be in the same socket, if processors are going to vary this widely? In is this a good thing?

If intel used just one socket, then you would have portions of a socket unused on some systems, but it would cost less to do the design, because there would be only one design. They don't do this because a socket with less pins costs less.

I don't know if that's what you wanted to know...

Intel and AMD could ostensibly remain eternally interchangeable; they are not and long have not been socket-level-compatible anyway. And they're not 100% interchangeable, if you fritter around at low levels you will find things that must be done differently on each processor, which is why [for example] the Linux kernel is configured differently for each.

The last time intel and AMD were socket-compatible was Socket Super 7.

how about not screwing the consumer oveR?

[Anonymous Coward]

how about not screwing the consumer over every 2 to 3 years and making some damn boards that will follow your processor road map? too much to ask?

Where all the CPU time will go

[Animats]

Where will all the CPU time go on desktops with these highly parallel processors?

• Virus scanning. Multiple objects can be virus scanned in parallel.
• Adware/spyware. The user impact from adware and spyware will be reduced since attacks will be able to use their own processor. Adware will be scanning all your files and running classifiers to figure out what to sell you.
• Ad display. Run all those Flash ads simultaneously. Ads can get more CPU-intensive. Next frontier: automatic image editing that puts you in the ad.
• Indexing You'll have local search systems indexing your stuff, probably at least one from Microsoft and one from Google.
• Spam One CPU for filtering the spam coming in, one CPU for the bot sending it out.
• DRM One CPU for the RIAA's piracy searcher, one for the MPAA, one for Homeland Security...
• Interpreters Visualize a Microsoft Office emulator written in Javascript. Oh, wait.

Re:Where all the CPU time will go

[walt-sjc]

Keep in mind that many of those tasks are also very I/O intensive, and our disk speed has not kept up with processor speed. With more cores doing more things, we are going to need a HELL of a lot more bandwidth on the bus for network, memory, disk, graphics, etc. PCI SuperDuper Express anyone?

Re:Where all the CPU time will go

[Vo1t]

Most of the features you mentioned require disk access. So when I try to open a file that is really important to me, it will be slower on a multicore than without those things (antivir, etc.) running in parallel.
What I would really like to see is improvement in real-time raytracing and radiosity. Something more like http://www.youtube.com/watch?v=oLte5f34ya8.

Re:Where all the CPU time will go

[spirit of reason]

Or a massive cache with extreme block sizes! Mwahahaha

Re:Where all the CPU time will go

[twitchingbug]

Well, I think the internal CPU memory bus is shared, for Intel anyways. Other I/O stuff (SATA, PCIe) are all point to point protocols no? So there's no I/O contention there. Of course, that doesn't help if you're all trying to access 1 disk, but then, yeah i agree with you.

Re:Where all the CPU time will go

[Joe The Dragon]

Will intles newer cpus have somethings like amd Direct Connect Architecture?
Will cpus be able to talk to each other without need to use the chip set?
Will they be able to have more then one northbridge like chip as there is in high end amd systems?
Will they have cache coherency?
Will you be able to have add on cards on the cpu bus like you can with HyperTransport?
Only having one chipset link for the pci-e slots, I/O, network, and etc. can be a big choke point in a 2-4+ cpu systems even more so with each cpu has 4+ cores.

Re:Where all the CPU time will go

[jafac]

Only on Slashdot, can it be ambiguous when something THIS Funny, is stamped Insightful.

Size doesnt matter to me.

[jshriverWVU]

I for one do a lot of cpu intensive coding, so I *would* use a 1thz processor. One thing I dont understand, they kept wanting to get more ghz for the same size an eventually hit a barrier. So why are we stuck on having a processor so small? I recently bought a 3ghz CPU and it was about the size of a 50 cent piece, and the actual core was smaller than a dime! 3ghz in less space than a dime! Cool, but why can't they just extend outwards?

I wouldn't mind going back to the days when computers were bigger if it meant I could have a 10ghz or 1thz computer. Let the computing begin.

Re:Size doesnt matter to me.

[RevHawk]

IANAS (I am not a scientist) But I thought I remembered hearing the size limitation has to do with the speed of light only being so fast - so if you make a cpu too large, you run into a delay issue because data can only move so fast. But, this might all be total BS. I did read it on Slashdot after all...

Re:Size doesnt matter to me.

[bcmm]

I don't think size is an issue really. Faster cycling doesn't come from adding transistors, it comes from making things happen faster. If anything, putting things closer together helps.

Re:Size doesnt matter to me.

[spirit of reason]

I've got it. I'll just redo the stages so that there are 334 times as many. Then we can clock your processor at 1 thz! And getting bigger will almost certainly not allow you to go faster, btw. If your goal is to improve the latency of the result for your instruction, you have to reduce the delay of the components (which smaller gates help) or do less in your instruction (which I was jokingly suggesting above) so you can turn up the clock speed (if heat weren't a problem). Adding more chip real estate will not make your add instruction go any faster. What you could do with it, though, is add more functionality by providing more instructions in the ISA, which the processor could accelerate with ever more transistors, at a higher price.

Re:Size doesnt matter to me.

[smoker2]

3ghz in less space than a dime! Cool, but why can't they just extend outwards?

Three words :
Speed Of Light
The clock speed (of a cpu) is limited by the speed of light, and the bigger the chip, the further stuff has to travel. Even at light speed, you can only go so far and get back again in a certain time.
I'm not brilliant at explaining this, but I'm sure someone else will pick this up.
In the meantime, have a look at this interesting paper from 2005.

Re:Size doesnt matter to me.

[gertam]

For one thing, size matters for the manufacturing process. The larger the chip of silicon, the more likely there is a flaw in it. If you increase the size of the silicon chip, you are likely to throw away many more flawed processors, wasting your time and money.

Re:Size doesnt matter to me.

[timeOday]

3ghz in less space than a dime! Cool, but why can't they just extend outwards?

Because the speed of light is too slow. No, seriously. You wanna run at 3 GHz? Light only travels about 4 inches in a clock cycle. Of course, you also need to allow time for switching - a processor is mostly a big bunch of switches, and they take a little time to respond to turn on and off.

Re:Size doesnt matter to me.

[Anonymous Coward]

you are likely to throw away many more flawed processors

or rename them Celeron, and sell at a discount.

Re:Size doesnt matter to me.

[Anonymous Coward]

>Three words :
>Speed Of Light

That is a crock. This is not a factor yet for microprocessor speed.

Re:Size doesnt matter to me.

[dgatwood]

And the speed of electrical propagation is even slower. In modern, copper-based chips, it's about 2/3rds the speed of light, IIRC. In the old aluminum-trace chips, I believe electrical propagation was even slower. The next gen will probably use carbon nanotubes, which reportedly provide faster propagation.

That said, your point still holds that you are constrained by the speed of electrical signal propagation in the trace medium (currently copper), and that short of changing that medium (and thus, the speed of propagation), the only way to increase speed beyond a certain point is to make the die smaller.

Re:Size doesnt matter to me.

[Tim_Enchanter]

Actually the speed of light has very little to do with it. It is true that the individual electron's travel near the speed of light, but the actual signal is limited by the RC delay. The speed of light is just the therotical maximun, but on silicon it is never truely approached. However wire delay, while notable, isn't the bottle neck. Just like others stated, the real bottle neck is the speed of the components. Making more transistors isn't going to speed up the chip, it will just add more functionality. Making FASTER transistors that drive smaller loads is what speeds things up.

Re:Size doesnt matter to me.

[init100]

It is true that the individual electron's travel near the speed of light

Ehrm, no. The electrons in an electric current travel very slowly, in the order of a few feet per second (maybe even lower). The signal on the other hand is propagated at a very high speed, such as a significant fraction of the speed of light. To use an analogy: Imagine that you have a thin pipe filled with peas. If you push another pea into one end, a pea will almost instantaneously fall out the other end. The peas themselves just moved a short distance though.

Re:Size doesnt matter to me.

[DNeoMatrix]

Okay yeah, unlike many of these posts which are mainly repeated are a little off. It has nothing to do with the speed of light. Electrons are not the same as light - they move at their own speed. It happens to be slower than the speed of light, but none-the-less. It depends on how far an electron can move through the semiconductors in a given time period. The more transistors, the more space it has to move in one clock cycle, so the clock speed has to be slow enough that the electrons can move throughout the entire circuit, but at the same time it cannot be too slow that race conditions develop. And unlike many people think, the electron itself is moving very (relative) slow (You can learn this in a standard high school AP Physics class), it is the effect of the electron moving, pushing the other electrons through the wire that moves very fast, but still much MUCH slower than light. The potential difference, a.k.a. voltage, comes from the difference in amount of electrons on one side versus the other side of a circuit, this difference causes the electrons at a higher potential push towards the lower potential until the difference has become 0, pushing the other electrons as they flow, like water in a river. While the water itself is not moving very fast, the water moving at the start of a river can cause a reaction at the bottom much faster than the water itself gets there.

Re:Size doesnt matter to me.

[Tim_Enchanter]

You are refering to the drift velocity, which is exactly that, the speed of the drift. The electrons are still traveling near the speed of light, they are just moving in all directions. The net drift is, as you say, very slow. Sorry if I was unclear on that. However, none of that changes the fact that the propogation of the signal is not limited by the speed of light, but by the RC delay.

Re:Size doesnt matter to me.

[Bin Naden]

Totally wrong. Someone parent down. Electrons do not move more than a fraction of a millimetre per second. It is actually the electric field along the conductor, which moves at the speed of light, that carries signal.

Intel's future can be summed up in just 3 letters.

[Anonymous Coward]

AMD

Programmable Cache/Storage

[Doc Ruby]

Cache's are cool, because they're automated to solve a common chip problem of faster access to more frequently used data, without any extra programming. But they're a pain, because they're a blob that extra programming can't do anything else with. If Intel could just add some programmatic access to core caches (including flushing and swap in/out to main or other-core memory), which otherwise could serve higher performance at some cycles, they'd solve a lot of these problems with little investment.

Conversely, chips like the Cell could include HW that makes their cores' local storage into caches.

Re:Programmable Cache/Storage

[serviscope_minor]

Intel have added some programmer control over the cache. Look at the prefetch, movnt and sfence instructions. They're only really hints, but they do help.

Time to dig out your instruction set manual... :-)

Re:Programmable Cache/Storage

[smallfries]

The 8800GTX is going this way with lockable cachelines and control over how jobs are split between core.

Begins At Microsoft With

[Anonymous Coward]

    Data Parallel Haskell

About time for some competition

[Anonymous Coward]

Not so long ago it seemed like there were more processors. Now it seems to be coming down to Intel, AMD and Power. The thing is that a lot of chips in the embedded world are as powerful as old Intel chips. Arm chips are able to run a minimal computer for instance. The joy of Linux is that it can be used on quite restricted chips. I wonder when we'll be able to buy consumer grade PCs with lower performance chips that Intel doesn't want to build anymore.

Some of the GPUs available now are a lot more powerful than even recent Intel chips. To heck with the computer, maybe we can run everything off the video card. :-)

Re:About time for some competition

[oakgrove]

I buy consumer grade PC's with chips Intel no longer wants to build all day at the pawn shop down the street.

News from the future

[Anonymous Coward]

The once el-cheapo knockoff of Intel/nVidia known as Awful Micro Devices/Awful Technologies INC has recently announced they have liquidated all of their assets to pay off all of their massive debts which includes all of their personal debts. Word has it all of the execs and stock holders are still in major debt and have committed suicide. There is even rumours of people at Microsoft committing suicide from massive debt including Steve Ballmer and his recently fiance Bill Gates. No word from Linus Torvalds, the now richest person in the world.

If you may recall Linus recently won a 150 Billion dollar lawsuit against Microsoft for using code that was under the GPL in Windows kernels ranging from Windows NT 4.0 to Windows Vista. The Supreme Court judges found that Microsoft violated the GPL and ordered Microsoft to pay Linus the 150 Billion dollar. Very desperate, Microsoft then invested in AMD/ATI in the attempt to keep their monopoly. They instead lost the rest of their money when most of the people went to Intel/NVidia for their support to GNU/Linux. GNU/Linux now has far better support for Windows software since the Judges ordered Microsoft to place all of their code into the GPL. The support for all Windows software far exceeds that of even Windows itself.

In other news the economy of all countries around the world are now in a state of improvement.

More energy efficient chips...

[Nim82]

I'd much rather they focussed on making chips more energy efficient than faster. At the moment barring a few high end applications most of the cpu power on the majority of current processors is largely unused.

I dream of the day when my gaming computer doesn't need any active cooling, or heat sinks the size of houses. Focussing on efficiency would also force developers to write better code, honestly its unbelievable how badly some programs run and how resource intensive they are for what they do.

Re:More energy efficient chips...

[MikShapi]

I second that.

I've just finished pulling apart my E6X00-based gaming box, in favor of a C2D T5500 mobile-on-desktop rig, replacing a fast FSB with a fanless(BIG-heatsink)-CPU and cutting CPU power consumption to almost 1/3. (Yes, I know an 8800 eats 250 Watts on idle. I'm still looking for a way to depower it and use alternative low-power VGA-out when not in use. Mention'em if you can think of'em)

L7200 and L7400's soon to hit the mobile-478-socket CPU market soon (thinkpad X60t's already ship with it), giving the same dual-core mid-range desktop performance for yet another 50% cut in power consumption - ~15 watts in place of ~30W, and knocking another 5W off for losing a fan or two.

Speaking of, any 478-mobile boards out there except for Gigabyte's GA-8I945GMMFY-RH that do both C2D (bumps the Asus N4L-VM) and PCIex16 (bumps the Abit IL-90)?

Re:More energy efficient chips...

[drinkypoo]

I'd much rather they focussed on making chips more energy efficient than faster.

Primary enemy of electronics is heat caused by inefficiency. By moving to a smaller process we reduce voltage, thus we reduce power (P=VI) and thus we reduce heat. So we can go faster. But we can also not go faster, and go lower power. VIA is the current leader, AFAIK, in low-power x86-compatible processors/systems. But beyond their equipment, much of which is very sad and slow, you can simply underclock any CPU and depending on the design, often run it at a lower voltage still.

Look into underclocking - the same work that went into making a faster processor also produced a lower-power processor. It simply isn't both at once.

I do wish processors would clock themselves down further. Core Duo T2600 peak is 2.16GHz, but it only goes down to 1GHz. Why not, say, 500MHz? Most of the time, two Core cores running at 500MHz would more than cover my CPU needs. It's only when I'm encoding video or playing a game or running a big report that I need all the processing power.

Re:More energy efficient chips...

[tknd]

Easy solution: get two computers. One for gaming and one for everyday tasks.

I've tried looking around for power efficient desktop parts and it's pretty much trial and error. For example I went through three desktop athlon 64 motherboards trying to find one with low power consumption but I could never get close to my laptop.

Once you've done that, the next thing I suggest is trying to run Vista (/ducks). You may laugh at first but I recently bought a dell c521 athlon X2 machine for my parents with vista business loaded on it. The machine supports a low power sleep state which consumes 2 to 3 watts at the outlet. That rivals many PSUs in standby mode! The nice thing about Vista's sleep state is that it comes back up practically instantly (2 to 3 seconds). You can literally just hit a key on your keyboard to wake up the computer and be working within 5 seconds.

The only problem with two different computers is now you have separate configurations (install certain software twice) and you have to come up with some way of sharing data between them. But I agree, I wish video manufacturers would start putting similar power saving technology as CPU manufacturers into their GPUs. The idle power consumption numbers are getting out of hand.

Re:More energy efficient chips...

[MikShapi]

Already doing that.
My other computer is an ultraportable dual-core T-5600-based Thinkpad X60.

Point is, my requirement is a bit different.

I game on an off, which is to say for 3 months I don't touch computers when I'm in school, then for 3 more I do some gaming. Cheaper (and nicer) to buy a graphics card for those months, then sell it off before the next semester. A proven way of getting a better academic record too ;-)

Still, I don't want to disassemble the entire desktop rig each time, and in school-era I want it to be a no-moving-parts box. This also means running its OS from a big&cheap CF card (and NAS for some stuff), careful choice of components and alternating between an tiny picoPSU-120 during peacetime to fuel the rig and a monster PSU for when a GPU monstrosity is present.

Re:Cell and parallel processing. Answer this for m

[Anonymous Coward]

"We don't need faster word processors."

No, but "we" seem to need to run ever larger and faster databases.

Yes.

[Anonymous Coward]

Are there any more questions from captain obvious?

Re:Still using pong and VT52 terminals

[Anonymous Coward]

Wow... you must be great fun at parties.

The future of Intel, with AMD following

[Anonymous Coward]

Cool, I guess whatever we read about the future of Intel chips is the same as reading about the future of AMD's chips, since AMD always follows Intel by at least a year, cloning whatever they do.

Re:The future of Intel, with AMD following

[spikestabber]

I guess thats why Intel cloned SVM and x86_64 huh?

Additionally

[Anonymous Coward]

Additionally, value-added features will lead to added improvements in additional quarters

You are a minuscule fraction of consumers.

[santiago]

New hardware is adopted because it's faster and/or cheaper. These days, the processor is only sometimes the critical component when it comes to speed. Slapping a new processor into an old system doesn't make that much sense, and the development cost of backwards compatibility with old hardware architectures to keep a tiny fraction of the Slashdot crowd happy simply isn't worth it. Computers have become commodities. When they break or get old, you throw them out and get a new one. No amount of whining will change this, because economics is against you.

Re:You are a minuscule fraction of consumers.

[toddestan]

On the other hand, Intel currently has:
LGA 775
Socket 478
Socket 604
Socket 771
Socket M
Socket P

Which is kind of silly. Not that AMD is currently any better.

Re:Still using pong and VT52 terminals

[fitten]

At the parties i go to, we don't waste our time playing video games, or editing documents.

...or having fun, I'd wager ;)

Re:Still using pong and VT52 terminals

[Anonymous Coward]

At the parties i go to, we don't waste our time playing video games, or editing documents.

Or talking to girls.

shitdot sheeple should slit their fucking wrists

[Anonymous Coward]

G0 & SLI7 Y0UR FUCKING WRIS7S FUCK7ARDED LINSUX FUCK7ARD!

New slashdork slogan:

[Anonymous Coward]

Slashdork - Ads for people, intel stuff

I just love corporate whores.

Energy Efficiency

[zentec]

The thing that is the future for Intel is not only the bizillion cores and cheaper/faster, but to do so with outstanding energy efficiency. This is obviously important for portable computing, but it's also important to reduce heat load and power consumption in large data centers. Cost of ownership comparisons have yet to include power consumption, but as green house gas taxes start making their way onto electric bills, it's likely to be a selling point.

More and more there's a need for extremely energy efficient, low footprint devices for special purpose applications. It just doesn't make a lot of sense to have PC sucking 60 watts when all you need is something to run Minicom to a simple 15" LCD screen.

Multiple cores appear as one

[gilesjuk]

That's what they need to do. Rather than make one chip look like two, it's easier to get max performance by making more than one core appear as one.

Re:Multiple cores appear as one

[Doctor Faustus]

Maybe to programmers, but the hardware doesn't work that way.

Tukwila CPU's

[adisakp]

One Tukwila, Two Tukwila, Three Tukwila, Floor!

What does this mean?

[nurb432]

If you cant figure it out, then why bother explaining?

Re:What does this mean?

[drinkypoo]

If you cant figure it out, then why bother explaining?

Because I have a hard time figuring out why anyone would say anything that stupid, including someone such as yourself whose nickname I recognize yet do not (yet) associate it with revulsion.

3D visualization, besides being an excellent tool for game development, is also used for a broad variety of real-world applications.

It's used in engineering, in molecular biology, in ordinary biology. It's used as a training tool, as well. The 9/11 incident heavily underscores the high value of computer-based training through simulation.

The same technology used in games is used for these purposes.

Re:What does this mean?

[nurb432]

Just a disclaimer: since this mostly is a throwaway forum with a lot of wierdos and idiots, i tend to have fun with people on here, so you have to take some of what i say with a grain of salt, and in the right context of poking at people. In a more worthwhile forum i dont. )

Now, that out of the way, I honestly believe a lot of what is being done today and being passed off as 'need' is a waste of resources. Most of the entire 'digital industry' is a waste as far as i am concerned. I feel the 'digital revolution' has far exceeded its usefulness and is actually now harming society as a whole. It has/had its place, but not invading every part of our lives as it does now.

And yes, i wear a windup mechincal watch to this day, and dont have fancy computer controlled components in my nearly 30 year old car. Wont ever buy another modern vehicle for the same reason. Oh, and guess what, just to be totally inconsistent, i actually make my living from supporting these infernal digital devices. But it doesnt mean i have to approve of how they are being (ab)used.

Re:What does this mean?

[drinkypoo]

Now, that out of the way, I honestly believe a lot of what is being done today and being passed off as 'need' is a waste of resources. Most of the entire 'digital industry' is a waste as far as i am concerned. I feel the 'digital revolution' has far exceeded its usefulness and is actually now harming society as a whole. It has/had its place, but not invading every part of our lives as it does now.

What you are experiencing is the "settling-out" phase that comes with every new technology. During the industrial revolution, cancer rates doubled without a corresponding increase in life expectancy. But now, each individual source of pollution tends to be dramatically cleaner than they were back then. Today, cancer rates are high, but we also live long enough to hit that wall when we should be, not prematurely.

I think actually that it's not at all the digital revolution that is the problem, but capitalism. We seem to be convinced (as a planet! the only thing we're on the same page about) that making money is the highest calling of man. For all their posturing, the people running the Chinese government live lives of opulence, so I think it's safe to say that they agree as well - actions speaking louder than words and all that.

Look around and you will see a lot of people complaining that they are broke while sitting on the couch watching their big screen TV. I am not much of an exception, except instead of big new shiny possessions I live in a nice house, and it sucks up a large portion of my income in rent. The problem is not that we're all using electronics all the time, the problem is that we're not happy with ourselves and we substitute possessions for inner peace.

And yes, i wear a windup mechincal watch to this day, and dont have fancy computer controlled components in my nearly 30 year old car. Wont ever buy another modern vehicle for the same reason.

I have nothing against wind-up watches (except that I've never owned a good one, and a good digital watch is a hell of a lot cheaper than a good mechanical one) but I have to part company with you on the car issue. I think that's nothing short of Luddism. Electronically-controlled cars are (when not implemented by idiots) more reliable and more efficient than purely mechanical ones. And besides, many cars of that era are computer controlled. Even when they are carbureted, anything made after California's emissions standards went up pretty much has an O2 sensor and a computer to match. They simply use a motor to adjust the mixture control.

Oh, and guess what, just to be totally inconsistent, i actually make my living from supporting these infernal digital devices. But it doesnt mean i have to approve of how they are being (ab)used.

No, of course. But it does definitely diminish the strength of your argument (as does having it on slashdot.)

Re:What does this mean?

[nurb432]

Just a side note: ive disabled 95% the electronic controls/senosrs on my cars. With it being that old i can get away with doing that and it still have it run :) about all that is left is the spark advance, and thats going to go when the engine gets swapped in a few years, with a vacuum controlled distributor. ( they dont last forever ). the rest is pure electricity, no 'brain' involved.

As far as making a living in the 'industry' and sounding like a hypocrite, it does give me a unique viewpoint of being someone on the 'inside' that has grown over the years to have a strong distaste for for where its heading. ( unfortunately ive been in it far to long to get out, we all gotta eat and have a roof to live under. )

I agree that i do have to pay more for some things, like my fountain pen, my watch, gas stove.. but at least i can make a statement in my personal life like this, with the acceptance of reality ( to avoid being called a ludite ) that one cant practically go 100% 'retro' as like above, you gotta eat.. and you have to interact with the rest of the world on their level, to an extent. At least in the USA anyway, in other countries, way out in the sticks, your milage may very..

( we are way OT now, and you get my *honest* point, since im not playing 'lets piss off the /.ers' )

Re:What does this mean?

[smallfries]

Is that you Theodore?

If anyone else read this thread all the way down to here then heed the warning. *Do not* open any post from nurb432...

How about:

[nurb432]

How about no. its inefficient and wasteful, and just plain wrong.

Re:How about:

[walt-sjc]

Come on, let's all revert to the bubble sort! But seriously, you are right. Not optimizing code is ridiculous. I have jobs that take 40 cores 6 months to execute (spread over 10 machines at the moment.) If by optimizing code I can drop that to 3 months, it's a huge win. Unfortunately, it's commercial closed source code and we can't fix it, and so we currently have a team working on rewriting the code using open-source / tools and we can release the improvements back to the community so that everyone benefits.

Amen, Brother

[trimbo]

As processors and bandwidth have gotten faster, the amount of crap people can dump on your screen to try to make a buck has increased significantly. Remember when we didn't used to go to a site because there were too many ads? Those days are long past, but have you tried an ad blocker? It makes browsing amazingly fast again. Or how about all the bloatware installed by Dell and HP? That kind of thing would have been intolerable 5 years ago, just on sheer processor speed.

It seems that any effort to optimize has gone out the window these days except for one consumer market -- gaming. Though I still think we're headed to a world with JITted Javascript. Hey, if Apple's iPhone SDK is Javascript, it seems to be the freight train of "progress" to use Javascript.

Re:Cell and parallel processing. Answer this for m

[LittleDobbs]

What we need is a change in paradigm at the OS level the in turn leads to the need to create a language that supports the paradigm. Something along the lines as Unix and C. For that to happen we need hardware that works efficiently in the existing paradigm while driving the paradigm shift.

I wish I had the answer to what the new system will look like, but I don't. If I did I would be working on creating it, but then again I don't have access to 200+ core processors :-)

My closest guess is something along the lines of todays distributed systems (i.e. Seta@home) but at the OS level. It can not be something that is as serial in nature as what we currently have. I imagine that there would also be something akin to callbacks. This is where I envision the need for new languages that make this process less painful then C yet can still get at the hardware like C does.

I say

[holywarrior21c]

it is now and it will be the fact that we need only 640 cores at a time.

Re:Still using pong and VT52 terminals

[walt-sjc]

After you've been married a while, you go to parties to ESCAPE talking to girls (or "a particular girl"... :-) Instead you may relax in your friends "Man Town" in the basement where he built a mahogany bar, setup the large screen, poker table, etc. and commiserate over the fact that your wives are draining the bank account because they decided for the 3rd time this year that the curtains in the living room just HAVE to be changed, that your teen kid busted through the end of the garage with the car, etc. Yes son, there is life after video games...

Re:Still using pong and VT52 terminals

[heinousjay]

Yes son, there is life after video games...

And with that rosey picture you've painted, I'm sure we'll all be lining up to join you in your incredibly stimulating lifestyle shortly.

Re:Cell and parallel processing. Answer this for m

[smallfries]

Use of the phrase "paradigm shift" - check
Use of "envision" - check
Incoherent rambling loaded with buzzwords and cliches - check

You sir, are a tool.

Re:Cell and parallel processing. Answer this for m

[keithjr]

There have been some attempts to streamline the process you describe already (libraries that involve small changes to existing code)
http://en.wikipedia.org/wiki/OpenMP
http://en.wikipedia.org/wiki/Message_Passing_Inter face
http://www.rapidmind.net/

The Rapidmind project showed some great benchmark results using the Cell.

Re:Still using pong and VT52 terminals

[Anonymous Coward]

"Man Town"? Dude, does that involve slings and glory holes, and getting drunk enough to be able to "forget" the manly activities in your friend's basement, and think you were just commiserating about your long marriage sex lives, rather than doing something about it?

The Sad State of Applications

[MasterOfGoingFaster]

I'm one of those 2% users - I run 3D CAD and FEA engineering apps. You'd think when you pay $20K for applications, it would take advantage of 64 bit multi-processor systems, since that stuff has been around for over 10 years, right? Every version of Windows NT since July 1993 has supported multi-processor systems.

I just got a new HP XW workstation - quad core Xeon, 16 GB RAM, 3 SCSI 320 drives. It's quite the hot rod. But my CAD system isn't much faster, since it only taxes one core. Worse, my FEA package is only 32-bit, so it can't use more than 2GB of RAM.

Meanwhile, I'm writing this on a 6 year old Athlon XP 2000 (1.6 Ghz) and 512 MB RAM, Windows 2000, Office 97. Believe it or not - _most_ of the time it doesn't feel any slower. The newer software sucks up all the added CPU power.

I do find that a faster single or dual core CPU does make a difference. But if you really want speed, get any modern CPU and run old software on it. The cheapest Athlon 64 running Windows NT 4 and Office 97 will freakin' fly.

It took 10 years for 32-bit apps to become mainstream after the introduction of the 386. Now that we have multi-core 64-bit systems, with 64-bit Operating Systems, I wonder how long it will take for our apps to catch up.

Re:Still using pong and VT52 terminals

[walt-sjc]

It's a joke son... But seriously, once you have been married for a while and socialize with other married couples, the women generally congregate separately from the men. This isn't a universal truth, but seems to happen more often or not. Also, it is generally regarded as inadvisable to hit on another mans wife especially while yours is with you, and her husband is there too. I have never EVER been to an adult party where the guys sit down and play video games...