Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 32nm 1000-Processor Array

vcl.ece.ucdavis.edu

Post reply on HN
Print view View original

51–60 of 107 posts

Re: A 32nm 1000-Processor Array

#51

Post by tremon »

geon wrote: post #46
endergen wrote: post #43

Earlier quoted context omitted.

I'm an ex game engine developer and I bristle anytime anyone thinks any existing functional language is better for multicore. Specifically garbage collection alone will make any language an order of magnitude slower generally per a single core. Also the C/C++ game development community at least has great approaches to multicore which makes C/C++ linearly scale with scores to boot, see for example: http://www.gdcvault…

> I bristle anytime anyone thinks any existing functional language is better The parent comment doesn't say that, though. I imagine current functional languages are about as ill suited as current imperative languages for running on a 1000 core machine. Something new might be needed.

I think that the concept of purity, present mostly in functional languages, helps a lot for writing parallellizable (?) code. My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment.

That said, few things in CS are written with this kind of parallellism in mind: even most algorithms' pseudocode is written in imperative style, and assumes the ratio of data to execution cores is on the same order as the data size itself.

We definitely need something new. Both on the algorithmic front and on the architectural front. I suspect that on this scale, you could easily need more than 10% of the computing power simply to feed the right data to the correct cores. A programmable memory management unit might be helpful.

Re: A 32nm 1000-Processor Array

#53

Post by digi_owl »

jacquesm wrote: post #33
willvarfar wrote: post #4

So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.

You program a machine like this much like you work with the unix command line when you string together a series of commands using 'pipes'. Only now the pipes are the comms links between the CPUs and the programs are the pieces of software executing on each of the CPUs, rather than that they all run on the same CPU. So it's more of a data flow model than a function-call model, and every node will transform its input r…

This layman finds himself reminded of the Cell CPU used in the Playstation 3.

Re: A 32nm 1000-Processor Array

#54

Post by ryao »

jacquesm wrote: post #38
mrb wrote: post #18

It is surprising the paper makes no comparisons with GPUs. So I will do it. For starters it looks like they are talking about integer operations (I only skimmed the paper and it mentions an ALU, not an FPU), whereas my GPU numbers below are single precision floating point numbers. So it is apples vs oranges. So, a modern 14-16nm GPU like the Tesla P100 or RX 480 does about 5 to 10 trillion ops/sec at 200-300 W, and a…

Another big difference is that most GPU architectures are multi-lane SIMD (so single instructions acting on multiple data but multiple sets of those) whereas the linked architure is MIMD. In simpler terms: these processors all execute independent code whereas a GPU tends to have multiple cores but a (sometimes much) smaller number of threads of execution.

Nvidia switched to MIMD in their Fermi architecture. I assume that they are the reason why jacquesm says most.

Re: A 32nm 1000-Processor Array

#55

Post by digi_owl »

bluedino wrote: post #47
jacquesm wrote: post #11

Earlier quoted context omitted.

Occam did it quite nicely. I think the reason transputers didn't 'make it' is not because they were super hard to program (it was only a little bit harder than programming a regular computer), but because the price premium you paid for a transputer set-up was too high and x86 got faster very rapidly. This is right around the time when the first 386 machines were launched and in a very short time we went from 12-20 MH…

>> x86 got faster very rapidly. Is ARM ( or something else) going to surpass x86 (amd64 whatever you want to call it) in the near future?

Just a layman, but i get the impression as of late that things are running into thermal and feature size issues.

And that these will affect all ISA equally.

Re: A 32nm 1000-Processor Array

#56

Post by geon »

tremon wrote: post #51
geon wrote: post #46

Earlier quoted context omitted.

> I bristle anytime anyone thinks any existing functional language is better The parent comment doesn't say that, though. I imagine current functional languages are about as ill suited as current imperative languages for running on a 1000 core machine. Something new might be needed.

I think that the concept of purity, present mostly in functional languages, helps a lot for writing parallellizable (?) code. My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. That said, few things in CS are written with this kind of parallellism in mind: even most algorithms' pseudocode is written in imperative style, and a…

> My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment.

Perhaps for use cases where current, garbage collected languages are suitable.

For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation, so you can be sure you won't need to collect garbage, at least in specific areas of the code.

Perhaps a stream-oriented language would be suitable? The runtime could spin up more cores as needed depending on back-pressure.

Re: A 32nm 1000-Processor Array

#57

Post by rntz »

Arguably the first 1000-processor chip was the CM-1, made in the 1980's: https://en.wikipedia.org/wiki/Connection_Machine

They also bury the lede somewhat. Apparently the KiloCore is a 1.78 Terahertz chip:

> The energy-efficient “KiloCore” chip has a maximum computation rate of 1.78 trillion instructions per second

Edit: they later say it's 1.78 GHz. I guess "trillion" is just a mistake?

Re: A 32nm 1000-Processor Array

#58

Post by deadgrey19 »

rntz wrote: post #57

Arguably the first 1000-processor chip was the CM-1, made in the 1980's: https://en.wikipedia.org/wiki/Connection_Machine They also bury the lede somewhat. Apparently the KiloCore is a 1.78 Terahertz chip: > The energy-efficient “KiloCore” chip has a maximum computation rate of 1.78 trillion instructions per second Edit: they later say it's 1.78 GHz. I guess "trillion" is just a mistake?

Maybe they mean "effective" speed. 1000x 1.78GHz = 1.78THz.

Assuming a job is embarrassingly parallel it might be an ok metric. Realistically, probably not.

Re: A 32nm 1000-Processor Array

#59

Post by deadgrey19 »

alexnewman wrote: post #49
greggman wrote: post #28

I'm certainly hopeful this will lead somewhere useful. Intel tried with Larrabee but apparently couldn't get the perf they wanted, especially with comparisons to GPUs It would be great to know what the trade-offs are with this architecture

you mean xeon phi. I think it's still around. It is plenty fast, but not much better tdp than a gpu (which are commodity (read this as cheap)).

Xeon Phi is around and used in various financial computations. The problem with GPUs is not TDP, but programming flexibility. Programming a GPU is very hard to do well for generic computations, whereas x86 like CPUs have millions of programmers who can do a pretty decent job.

Re: A 32nm 1000-Processor Array

#60

Post by mafuyu »

rntz wrote: post #57

Arguably the first 1000-processor chip was the CM-1, made in the 1980's: https://en.wikipedia.org/wiki/Connection_Machine They also bury the lede somewhat. Apparently the KiloCore is a 1.78 Terahertz chip: > The energy-efficient “KiloCore” chip has a maximum computation rate of 1.78 trillion instructions per second Edit: they later say it's 1.78 GHz. I guess "trillion" is just a mistake?

Instructions Per Second is different from the clock speed. In this case, it looks like each core is ~1 Instruction Per Clock, so 1 * 1.78 GHz * 1000 cores.

The trick is that getting 1.78 trillion IPS distributed over 1000 cores is very different from getting that over a few cores.

Post reply on HN