New Processor Will Feature 100 Cores

[The Straight Story]

Gadget Lab Hardware News and Reviews
New Processor Will Feature 100 Cores

Forget dual-core and quad-core processors: A semiconductor company promises to pack 100 cores into a processor that can be used in applications that require hefty computing punch, like video conferencing, wireless base stations and networking. By comparison, Intel’s latest chips are expected to have just eight cores.

“This is a general-purpose chip that can run off-the-shelf programs almost unmodified,” says Anant Agarwal, chief technical officer of Tilera, the company that is making the 100-core chip. “And we can do that while offering at least four times the compute performance of an Intel Nehalem-Ex, while burning a third of the power as a Nehalem.”

The 100-core processor, fabricated using 40-nanometer technology, is expected to be available early next year.

In a bid to beat Moore’s law (which states number of transistors on a chip doubles every two years), chip makers are trying to either increase clock speed or add more cores to a processor. But cranking up the clock speed has its limitations, says Will Strauss, principal analyst with research and consulting firm Forward Concepts.

“You can’t just keep increasing the clock speed so the only way to expand processor power is to increase the number of cores, which is what everyone is trying to do now,” he says. “It’s the direction of the future.”

http://www.wired.com/gadgetlab/2009/10/tilera-100-cores/

In fact, Intel’s research labs are already working on a similar idea. Last year, Intel showed a prototype of a 80-core processor. The company has promised to bring that to consumers in about five years.

[Recursion]

1. Current chips are fast enough -- improve the compilers

80 cores, 100 cores, 1000 cores: won't mean a dang thing if your compilers cant schedule well, or if your i/o model is stupid (which it inevitably is). CPU's haven't been the choke point on speed in about a decade and a half.

[phantom power]

2. CPU cache memory misses are one of our biggest bottlenecks.

A CPU with big honking cache, or faster RAM->cache transfer, would speed up a lot of our stuff.

To say nothing of faster disk. And by the way, it would be nice if Windows would ever see fit to optimize their damned disk IO. We routinely measure 4x disk-access improvements, just by building on linux. Same machine, same disk. Just running on linux speeds things up by 4x.

If Microsoft had any pride, they might be ashamed of that.

[Swamp Rat]

4. 2.6.31.5

:)

[Recursion]

5. 4.6

:)

[Statistical]

7. We routinely see 80 brazzilion times disk-access improvement just by compiling in windows.

Hell even windows 98 is about 984023840934832904823904x faster than Linux.

(Wow nonsensical statements are fun)

[cliffordu]

11. Well of course. If you completely ignore the BSOD during compilation,

then it's faster than all get out.

[Realityhack]

3. Depens upon the application.

I do not think that is true as a universal statement.

[Recursion]

6. Sorry, EE grad student moment there. I was assuming embedded systems

The problem for a while has been getting data into and out of processing, not processing itself, for most embedded applications.

[Realityhack]

8. I understand. I just didn't want others to think it was universally true. n/t

[Recursion]

14. Then again, memristors may change everything

Flash memory at twice RAM speeds... that could bring processing back to being the bottleneck.

[boppers]

9. Improve the compilers? The compilers are fine.

Compilers, after all, are simple translators. That's like blaming a poor racing performance on a car's engine... when the driver and crew has decided that the vehicle cockpit needs a mini-bar, a jacuzzi, a bed, a trophy room, and seating for 15. Simple programs get slowed down with insane amounts of bloat, add-ons, and widgets, just to, oh.... type up a document or render a web page. (Classic example: A talking paperclip? Really?)

A friend of mine wrote this back in 1983:
http://www.pbm.com/~lindahl/real.programmers.html

...and it's even truer today. Languages have changed, but there's still a massive gap between programmers who know how to write efficient code and "programmers" who think their code just needs a faster CPU, or a better compiler, or a more efficient library, or better caching, or <insert somebody else's problem here>, rather than simply writing good code to start with.

[Recursion]

10. We're talking specifically about parallelism here

And that is an issue with the compilers. If you can't properly schedule execution, more cores can end up slowing down execution time.

[boppers]

12. Parallelism has been fairly understood for many years now, at the compiler level.

The D825 came out in 1962. Multics came out in 1969.

It's possible to write code for multi-core (or multi-node) properly, and it's also possible to write code that processes/threads/scales poorly.

At one extreme, there's google's system, who has over a million cores in their system, with multiple nodes that just do scheduling and load distribution between the nodes. At the other end, there are also lots of programs that were *never* written with multiple processes/threads in mind, and thus, sit on a single CPU while the other CPU's sit idle.

To paraphrase your statement:
If a programmer can't (or doesn't) properly plan execution, more cores can end up slowing down execution time.

[Statistical]

13. However parallel is much harder to get right and much much easier

to introduce bugs than single threaded (or lightly multithreaded app).

One only need to look at benchmarks of games and other apps on single, double, triple, and quad core.

The tools have been rather lacking on multicore optimization on x86/x64 platform. This is changing slowly but generaly speaking I would rather have a 12GHz single core (w/ hyperthreading) than 3Ghz quad core.

Of course netburst failed and we are never getting 12Ghz so we need to bite the bullet but maximizing performance on multicore enviroment is no easy task.

[boppers]

15. I agree, to an extent.

In a "mechanical engine RPM" metaphor, we have an entire generation of programmers who kept hoping that faster engines would be a solution, so a 12Grpm, single cylinder, vehicle engine would be hypothetically better than a six-cylinder, 3Grpm, vehicle engine. (We know how that turned out, both for the good and bad).

These engine engineers would have to learn about fuel distribution, EFI, balancing, firing sequence... a whole host of things in order to make better engines. Yes, it's much harder.

That's why it's a job, and why software is "engineering", and not "I get paid mad amounts of money to type up object templates that reduce a CPU to massive in-efficiency".

[Statistical]

16. Of course.

No excuses however it is the simple reality that writing effective, efficient multithreaded code is often requires substantially more time to plan, code, and test. Given in software time = product cost often companies are reluctant to explore multi-threaded programing unless there is no other choice.

For a long time (60mhz - 3000 Mhz) there was the "easy way out" however we will never see that increase in frequency again so the industry will have to accept either a) more efficient code or b) developing multithreaded solutions. Doesn't mean the transition will be easy.

Recently there has been a lot of development in tools to assist in creation and testing of multithreaded apps so I am optimistic.

Intel Parallel Studio
http://software.intel.com/en-us/intel-parallel-studio-home/

Microsoft Parelel Tools for Visual Studio 2010
http://msdn.microsoft.com/en-us/concurrency/default.aspx

[boppers]

17. Shameless bump for DU's resident geeks.

I'm doing minor parallelism with 16-127 processes, on systems with up to 9 machines, 8 cores each (72 CPU cores) what are others doing?