Comments on: Meta Sees Little Risk in RISC-V Custom Accelerators https://www.nextplatform.com/2023/12/01/meta-sees-little-risk-in-risc-v-with-custom-accelerators/ In-depth coverage of high-end computing at large enterprises, supercomputing centers, hyperscale data centers, and public clouds. Thu, 14 Dec 2023 21:36:08 +0000 hourly 1 https://wordpress.org/?v=6.7.1 By: Hubert https://www.nextplatform.com/2023/12/01/meta-sees-little-risk-in-risc-v-with-custom-accelerators/#comment-217068 Sun, 03 Dec 2023 01:43:35 +0000 https://www.nextplatform.com/?p=143330#comment-217068 In reply to Slim Albert.

I’m no expert in this but the difference seems to be where design sliders are set in relation to (1) the amount of dedicated memory per computational core (eg. near-memory compute, minimal latency, proper bandwidth, not shared), and (2) the degree to which the underlying NoC or interconnect can simultaneously (and independently) shuffle computed outputs from any core to any other core to form a deep (and efficient) software-configurable “macroscopic” parallel computational pipeline (dataflow).

SambaNova’s (PasoDoble?) Reconfigurable Dataflow Units (RDUs), Groq’s Software-defined Scale-out TSP (or LPU?), Cerebras’ waferscale neocortex with 2D mesh interconnect (and new “weight streaming” mode), and Tenstorrent’s “dataflow machine [that] can send data from one processing element to another” ( https://www.nextplatform.com/2023/08/02/unleashing-an-open-source-torrent-on-cpus-and-ai-engines/ ) have set secret sauce sliders on the side that looks best for AI acceleration. If I’m not mistaken, MTIA, Veyron, and Sophon set their sliders towards a more static inter-core network design and less dedicated memory per core, making them best for (maybe) HPC applications [*](like A64FX, Rhea1, …)?

[*] Note: HPC applications as considered separately from dynamic-language-based DC applications that commonly require register-based or stack-based abstract/virtual machines and automated garbage collection among others (Java, Javascript, Python, Scheme, Julia, Lua, Erlang, Smalltalk, …).

]]> By: Roger https://www.nextplatform.com/2023/12/01/meta-sees-little-risk-in-risc-v-with-custom-accelerators/#comment-217066 Sun, 03 Dec 2023 00:02:22 +0000 https://www.nextplatform.com/?p=143330#comment-217066 No matter it’s a X86, ARM, Power64, Power64le, RISCv64, S390x server or device, when you run Linux on it, only our software can provide the true zero trust environment for users to run commands on it.

]]> By: Slim Albert https://www.nextplatform.com/2023/12/01/meta-sees-little-risk-in-risc-v-with-custom-accelerators/#comment-217036 Sat, 02 Dec 2023 04:57:21 +0000 https://www.nextplatform.com/?p=143330#comment-217036 Quote: “Meta is skipping the ubiquitous GPU and building AI inference and a training chip on RISC-V”

Way to go! But I’m not sure if MTIA ( https://www.nextplatform.com/2023/05/18/meta-platforms-crafts-homegrown-ai-inference-chip-ai-training-next/ ) can beat the dataflow designs of Tenstorrent, Groq, Cerebras, and PasoDoble, that implement forms of configurable “near-memory” compute. MTIA is more reminiscent of the server-oriented 64-core Sophon SG2042 that SC23 found to be somewhat lacking in performance.

]]> By: Slim Jim https://www.nextplatform.com/2023/12/01/meta-sees-little-risk-in-risc-v-with-custom-accelerators/#comment-217027 Fri, 01 Dec 2023 23:55:40 +0000 https://www.nextplatform.com/?p=143330#comment-217027 Using RISC-V as a basis for developing custom accelerators makes sense to me, especially as such development might be quite exploratory, and proof-of-concept may occur through prototyping on an FPGA. NIOS, NIOS II, PicoBlaze and MicroBlaze are proprietary, and either 8-bit or just 32-bit. LatticeMico8 and 32 are more open, but also top out at 32-bits. ARM core instances (eg. 32-bit Cortex-A9) are found in many FPGAs but are not freely customizable that I know of (hard). Accordingly, RISC-V offers the better prospect, especially in the most relevant field of 64-bit device development.

In my opinion, ARM’s RISC risks losing out to RISC-V in 2 areas here. Firstly, they should already have a 64-bit microcontroller profile (say Cortex-E) in the field, to embed deeply in hardware and edge devices where RISC-V is finding a welcoming niche for itself (including HDDs for example) — 32-bit microcontrollers are a bit long in the tooth these days. Secondly, they should have an open source cutomizable FPGA profile for these 64-bit units (say Cortex-F), with a simplified version of that arch, to allow folks to freely tinker with it, and possibly develop and prototype ARM-based accelerators at low cost (in their labs, studio garages, or bedrooms). This may take the form of their Cortex-M1 and M3 free use soft IP programs ( https://www.arm.com/resources/free-arm-cortex-m-on-fpga ) but at the 64-bit microcontroller level — those could readily beat the pants off of just about any RISC-V device out there in my view! Better yet if they’d pack this straight into Yosys, resulting in a most exceptional “voilà”!

]]>