2 ms·

Illustrating with the cliche... they ignore you they laugh at you they fight you <======= you win Now, for something substantial to say... I was look

Illustrating with the cliche... they ignore you they laugh at you they fight you <======= you win Now, for something substantial to say... I was looking into computers that can run heavily parallelized grep, and I looked at Adapteva's 16-core Parallella and their 1024-core Epiphany thing, which I think are based on RISC-V (possibly an extension thereto) (EDIT: I'm wrong, see below). It seems that the sole engineer of Adapteva had "left Adapteva in January [2017] to take a position as a program manager at DARPA", and that's the last blog post from the company's website. So... Is anyone working on anything like that, that is currently available or close to available?

_chris_ 8y ago
Adapteva did not use RISC-V. Andreas Olofsson said that, if there was another version, he would probably use RISC-V. [http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in-my-next-chip/ http://www.adapteva.com/andreas-blog/why-i-will-be-using-the...]
vidarh 8y ago
I don't know of anyone doing something similar. GreenArrays is the closest I'm aware of in terms of number of cores, but their cores are far more minimalistic. XMOS Xcore is another one that is similar-ish. One of the problems Adapteva kept facing, and that I think XMOS did too (and that's caused their change in focus to specifically market voice processing solutions rather than focus on their chips), is that they're suited for a very specific nice: Larger CPUs are way better for things that need high single-core performance and are hard to decompose. GPUs are way better for anything that's mostly single-instruction multiple-data. That is, anywhere where you have a small number of instruction streams doing the same two large arrays. Things like Epiphany and XMOS Xcore do have some appeal in really low power applications, but they'll do best in cases where you have multiple fundamentally divergent instruction streams (lots of branching). Even then, you need enough cores that you can't just pick a bigger CPU and timeslice. Conceptually it really appeals to me, but ever since the days of the Transputer, we've struggled to decompose problems well enough to make many-core designs like Epiphany compete well with ever-faster single-core performance and now coupled with GPU's to slice away the SIMD type problems. I'm still a fan, and have two Parallelas, and find it really sad that he wasn't able to get more traction, as I think you need to get it to an inflection point with more RAM per core and more cores per chip (the Epiphany V might have done that if it had become commercially available, or e.g. on a PCIe card) to allow people to more realistically find the right problems to solve on them. Part of the challenge is that unlike for GPUs, there are no problems that are really screaming out for this architecture, especially not as single core performance for CPUs have skyrocketed, and you can compensate for the lower number via multithreading. For Epiphany type architectures to make sense you need problems where slow-ish single thread performance can be compensates by an ability to run far more in parallel and/or where deterministic latency for communication that is easy to reason about can compensate (e.g. for Epiphany you can relatively easily count "hops" to know how many cycles accessing the memory of any given other core will take, so if you're careful you can use that to do lock-free memory accesses across cores).

_chris_ 8y ago

Adapteva did not use RISC-V. Andreas Olofsson said that, if there was another version, he would probably use RISC-V. [http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in-my-next-chip/ http://www.adapteva.com/andreas-blog/why-i-will-be-using-the...]

vidarh 8y ago

I don't know of anyone doing something similar. GreenArrays is the closest I'm aware of in terms of number of cores, but their cores are far more minimalistic. XMOS Xcore is another one that is similar-ish. One of the problems Adapteva kept facing, and that I think XMOS did too (and that's caused their change in focus to specifically market voice processing solutions rather than focus on their chips), is that they're suited for a very specific nice: Larger CPUs are way better for things that need high single-core performance and are hard to decompose. GPUs are way better for anything that's mostly single-instruction multiple-data. That is, anywhere where you have a small number of instruction streams doing the same two large arrays. Things like Epiphany and XMOS Xcore do have some appeal in really low power applications, but they'll do best in cases where you have multiple fundamentally divergent instruction streams (lots of branching). Even then, you need enough cores that you can't just pick a bigger CPU and timeslice. Conceptually it really appeals to me, but ever since the days of the Transputer, we've struggled to decompose problems well enough to make many-core designs like Epiphany compete well with ever-faster single-core performance and now coupled with GPU's to slice away the SIMD type problems. I'm still a fan, and have two Parallelas, and find it really sad that he wasn't able to get more traction, as I think you need to get it to an inflection point with more RAM per core and more cores per chip (the Epiphany V might have done that if it had become commercially available, or e.g. on a PCIe card) to allow people to more realistically find the right problems to solve on them. Part of the challenge is that unlike for GPUs, there are no problems that are really screaming out for this architecture, especially not as single core performance for CPUs have skyrocketed, and you can compensate for the lower number via multithreading. For Epiphany type architectures to make sense you need problems where slow-ish single thread performance can be compensates by an ability to run far more in parallel and/or where deterministic latency for communication that is easy to reason about can compensate (e.g. for Epiphany you can relatively easily count "hops" to know how many cycles accessing the memory of any given other core will take, so if you're careful you can use that to do lock-free memory accesses across cores).