Hacker News Reader

Comment by speed_spread | Hacker News Reader

The IO and RAM for that many cores would be a bottleneck. If you manage to keep everything local to a core or a group of cores then you'll severely constrain the kind of programs you can run.

View on HN

Right. However, we've had GPUs as compute engines for a while now. People have gotten better at getting massively parallel architectures to do something useful. Both machine learning and graphics fit that model.

There have been many dead ends in that space, though. Thinking Machines and the Cell processor come to mind.

Indeed, a GPU is effectively a massive grid of RISC cores (and accessing global memory is a major bottleneck). I do think that "a GPU but RISCV" is an interesting proposal, but I doubt the major players would be willing to abandon their existing instruction sets

It’s clear that coherent shared RAM has no chance of working in such a setting, but how plausible would it be to do some sort of explicitly networked grid interconnect like on the Epiphany or GreenArrays chips?

(My layman’s feeling always was that the GA model of a large network of small and stupid CPUs was underappreciated and hampered by GA’s merciless pricing as a possible FPGA replacement, given how painfully bad the latter are at utilizing the capabilities of modern IC technology—single layer, really?—but I’m not sure how true that is either.)

> It’s clear that coherent shared RAM has no chance of working in such a setting

It's not clear to me actually. You can run cache coherence protocols over a network, they'll just be slow. (But not any slower than message passing would be anyway.)

The Esperanto system with lots of RISC-V cores is built with localized memory for small clusters of cores. It is programmed akin to a graphics card and plenty of workloads are done on graphics cards. That means it screams on machine learning, crypto, scientific computing and many other number crunching tasks. Sure it will not make your MS Word run 1 million times faster but who needs that?

It's pretty much the same idea as "compute in memory", which is generally considered good wrt. memory bandwidth per performed instruction. Keep everything as local as possible, don't go through a costly Von Neumann bottleneck between a powerful CPU and a large, sparsely accessed RAM.

Reply on news.ycombinator.com