Hacker News Reader

Comment by amelius | Hacker News Reader

One of the big difficulties with conventional processors is the memory hierarchy, where the entire memory is viewed as a shared memory space. There is no information in the article on how these processors communicate, so I'm guessing that this processor side-stepped the entire shared memory issue by offering only local memory combined with a simpler form of communication (e.g. message passing).

View on HN

This is reminiscent of Parallella [1]/Epiphany (which unfortunately failed to gain traction). They didn't release any designs with core counts like that, but the entire point of the design was to enable large numbers of cores with in-core memory and predictable latency for accessing the memory of cores elsewhere in the grid.

Epiphany did have (slower) access to external memory too, but the challenge of these architectures is finding problems that requires too much branching to be able to take proper advantage of GPUs, yet so parallel that relatively low single-core performance is outweighed by throwing more cores at it and/or where the low power usage of the Epiphany would be worth it, and it seems they just didn't find enough of a market for it.

I have two of the kickstarter boards sitting around. Wish they'd gotten larger scale versions out.

[1] https://www.parallella.org/

I have two of those boards too. They were working on a 1024 core version, but alas, they didn't survive as a company to make it.

Also arguably spiritual descendants of the Transputer?

Yes, there are definitively similarities in concept. The whole idea of an on-chip network between cores stems from the Transputer as far as I know.

Reminds me of the PS/2 CELL Architecture, with the SPUs having limited local memory, and needing to DMA stuff around in a streaming fashion to build up larger programs.

The Cell was a pain to program because of that hateful memory architecture. The anemic PowerPC CPUs didn't help much either.

Nothing really prevents an architecture where part of the address space is core-local (with low latency) and not directly accessible from other cores, and the rest points to a (much higher latency) shared memory pool. I have a feeling this would be much nicer to program than a Cell or the average GPU.

> Nothing really prevents an architecture where part of the address space is core-local (with low latency) and not directly accessible from other cores, and the rest points to a (much higher latency) shared memory pool. I have a feeling this would be much nicer to program than a Cell or the average GPU.

Many GPU's have this kind of local scratchpad memory. Nvidia GPU's even allows the programmer to partition the local SRAM between the scratchpad memory (called shared memory in CUDA docs) and L1 cache.

It's a shame nobody came up with an OS that runs entirely on a GPU.

Seems like the way to go ... maybe even 3 layers of memory -- core local memory, memory that provides shared reader and writer consistency, and memory that provides shared reader, single writer consistency (for ownership transfers). Maybe the second form doesn't actually need to exist at all?

Minimizing ownership transfer cost across hardware elements seems like a fundamental concept to me that future architectures will need to specifically optimize in order to maximize the benefits that can be reaped from "task specific" hardware.

The more cores we add the more we have to gain by allowing them to be different from each other I think ...

Nevertheless people were able to harness the Cell for good performance. It took a re-think and I am not denigrating your experience but our experience was that we benefited everywhere when we reorganized our data and algorithms around the SPUs.

That was the PS3.

Yep, at KnuEdge we built some processors with thousands of cores in that style architecture. It's a bit different to reason about but you can do a lot of wild computing that way. Too bad the company folded before any of our processors were available.

Yes, "Cores operate at an average maximum clock frequency of 1.78 GHz, and they transfer data directly to each other rather than using a pooled memory area that can become a bottleneck for data."

This makes sense, everyone loves debugging MPI programs, so of course we'd want to replicate that experience on the desktop.

You might have to be dragged kicking and screaming to the multicore because CPUs aren't getting faster.

The distinction here is between distributed and shared memory, not between single and multicore programmming. Distributed memory is more often used on clusters. I would say distributed memory is generally considered easier on the hardware, harder on the programmer (although one could argue that a message passing communication scheme is more explicit than fork/join, so the programmer has more control).

Reply on news.ycombinator.com