Intel Pledges 80 Core Processor in 5 Years

ZonkerWilliam writes "Intel has developed an 80 core processor with claims 'that can perform a trillion floating point operations per second.'" From the article: "CEO Paul Otellini held up a silicon wafer with the prototype chips before several thousand attendees at the Intel Developer Forum here on Tuesday. The chips are capable of exchanging data at a terabyte a second, Otellini said during a keynote speech. The company hopes to have these chips ready for commercial production within a five-year window."

Comments

Apple and Microsoft and BSD better hurry and scale

[Lost Found]

This is hilarious, because if this goes out on the market there's not going to be many operating systems capable of scheduling on that many chips usefully. OS X can't do it, Windows can't do it, and nor can BSD. But Linux has been scheduling on systems with up to 1,024 processors already :)

Re:76 too many cores?

[Bluesman]

How many processes are running on your machine?

A basic strategy would be for the OS to devote each process to its own processor.

This would reduce the need for TLB/cache flushes or eliminate context switches entirely. The whole machine would be really snappy.

That said, for a desktop machine, this is a huge amount of overkill, but with economies of scale being what they are, we'll probably have this power available soon.

What I'd like to see more though, is extra functionality in hardware rather than more of it. Wouldn't it be great if hardware was able to handle some of the things an OS is now used for, like memory (de)allocation? Or if we could tag memory according to type? Or if there were finer-grained controls than page-level?

nVidia should be worried....

[stonewolf]

A couple of things to mention here. Many years ago I read an Intel road map for the x86 processors. It was more than 10 years ago, less than 20 I think. In it they said they would have massively multicore processors coming along around now. They may have forgotten that and reinvented the goal along the way, companies do that. But, they really have been predicting this for a very long time.

The other thing is that with that many cores and all the SIMD and graphics instructions that are built into current processors it looks to me like the obvious reason to have 80 cores is to get rid of graphics coprocessors. You do no need a GPU and a bunch of shaders if you can throw 60 processors at the job. You do need a really good bus, but hey, not much of a problem compared to getting 80 cores working on one chip.

With that kind of computer power you can throw a core at any thing you currently use a special chip for. You can get rid of sound cards, network cards, graphics cards... all you need is lots of cores, lots of RAM, a fast interconnect, and some interface logic. Everything else is just a waste of silicon.

History has shown that general purpose processing always wins in the end.

I was talking to some folks about this just last Saturday. They didn't beleive me. I don't expect y'all to believe me either. :-) The counter example everyone came up with was, "well, if that is true why would AMD buy ATI?" The answer to that is simple, they want their patent portfolio and their name. In the short term it even makes sense to put a GPU and some shaders on a chip along with a few cores. At the point you can put 16 or so cores on a chip you won't have much use for a GPU.

Stonewolf

Re:nVidia should be worried....

[sp3d2orbit]

I remember doing a project in college where we had to implement a 8 point FFT in software and hardware. I was eye-opening. The hardware implementation ran on a FPGA that had something like a 23Mhz clock. The software solution was a C program running on a 2Ghz desktop. 23 Mhz vs. 2 Ghz. The hardware solution was more than 10X faster.

I don't think that general purpose processors will ever completely replace special purpose hardware. There is simply too much to be gained by implementing certain features directly on the chip.

Re:Apple and Microsoft and BSD better hurry and sc

[Profane MuthaFucka]

In other words, get out your functional languages like Haskell and OCaml and use the side-effect free feature set to develop multi-threaded programs. Or do it the hard way with an OO language.