RISC vs. CISC: The Post-RISC Era (1999) • Hacker News Board

Re: RISC vs. CISC: The Post-RISC Era (1999)

#21

Post by zozbot234 » Thu, Jan 05, 2023, 12:54 PM UTC

speed_spread wrote: post #10

stefanpie wrote: post #7

During a recent conference I attended, a keynote speaker discussed their idea of having CPUs with at least 10,000 RISC-V cores and servers with one million RISC-V cores [1]. The idea is appealing, but how feasible is it and how does RISC make this possible or useful? I'm just curious what people think about this. [1]: https://www.microarch.org/micro55/media/keynote_ditzel.pdf

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.

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.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#22

Post by menaerus » Thu, Jan 05, 2023, 1:21 PM UTC

drmpeg wrote: post #20

Dave Ditzel (mentioned in the article) is still involved with RISC architectures. His current company Esperanto is shipping a 1088 core RISC-V processor. https://www.youtube.com/watch?v=5foT3huJ_Gg

To be clear, I understand that the chip is built from 4 general-purpose OOO RISC-V cores, one service (?) processor and the rest of them (1088) are intended for GPU-like compute.

Then they build the compute by using Ice Lake Xeon to drive such 8x SoCs, where each of those SoCs are hosted on their own dedicated PCIe 4.0 slot. And then they upscale the whole thing to a dual-socket system which then translates to 17408 vector/tensor cores and 80 GP cores or ~17.5K cores in total.

Pretty exciting.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#23

Post by zozbot234 » Thu, Jan 05, 2023, 1:28 PM UTC

mananaysiempre wrote: post #14

speed_spread wrote: post #10

Earlier quoted context omitted.

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.

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…

> 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.)

Re: RISC vs. CISC: The Post-RISC Era (1999)

#24

Post by kllrnohj » Thu, Jan 05, 2023, 1:31 PM UTC

socialdemocrat wrote: post #13

Interesting to see John conclude like me after reading Patterson that RISC vs CISC was always about a philosophical difference in how you approach chip design. This is what I argue in this article as well but I reach a different conclusion from him and I think that is in large part because the rise of RISC-V has made the RISC and CISC distinction more relevant again. https://itnext.io/risc-vs-cisc-microprocessor-phil…

Does it really though? Isn't RISC-V continually adding new complexity as it attempts to scale up from an ISA only useful for microcontrollers to one more competitive beyond that?

The entire extension system seems pretty "CISC-y" does it not?

Re: RISC vs. CISC: The Post-RISC Era (1999)

#25

Post by fastaguy88 » Thu, Jan 05, 2023, 1:49 PM UTC

I am curious. As I understand it, both RISC and CISC processors are implemented in microcode for the actual hardware gates on the chip. And perhaps different hardware generations make it easier to build different micro-code machine architectures.

So why not just offer an instruction set that matches the base hardware architecture? Rather than have all that decoding done on the chip, why not by a compiler? I understand that branch prediction can only be done at run time, but presumably there is some "closer to the metal" instruction set that would be faster than instruction decoding. Or is instruction decoding very low cost?

Re: RISC vs. CISC: The Post-RISC Era (1999)

#26

Post by bogomipz » Thu, Jan 05, 2023, 1:49 PM UTC

Animats wrote: post #11

The two extreme cases still existed in that era. One extreme was the DEC VAX. The instruction set is complex, convenient, high level, and slow. The other extreme was the original IBM 801, which led to the IBM POWER architecture. In its pure form, it was one instruction per clock, had lots of registers, and was quite simple. MIPS went down that road in a big way. Then CISC microprocessors became superscalar, and start…

>"The instruction set is complex, convenient, high level, and slow."

Could you elaborate on how The DEC VAX ISA was complex yet also convenient? I feel like those two characteristic are at odds with each other. Or does complexity and convenience refer to different aspects i.e implementation vs use?

Re: RISC vs. CISC: The Post-RISC Era (1999)

#27

Post by leeter » Thu, Jan 05, 2023, 1:56 PM UTC

fastaguy88 wrote: post #25

I am curious. As I understand it, both RISC and CISC processors are implemented in microcode for the actual hardware gates on the chip. And perhaps different hardware generations make it easier to build different micro-code machine architectures. So why not just offer an instruction set that matches the base hardware architecture? Rather than have all that decoding done on the chip, why not by a compiler? I understan…

To answer the last question first: Yes instruction decoding is dirt cheap (generally speaking) the thing that slows down a CPU is memory model, register retirement etc.

In theory RISC was intended to be basically no microcode where the CPU would expose the hardware instructions. In reality that is done to an extent but superscalar basically made the advantage that had mostly obsolete. This left RISC having the main advantage of having a ton of registers which does simplify other things when designing a superscalar CPU. But at the end of the day most architectures are falling into the "FISC" singularity where speed is all that matters. This is why AARCH64 was deliberately designed to be insanely superscalar from the ground up.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#28

Post by Macha » Thu, Jan 05, 2023, 1:56 PM UTC

fastaguy88 wrote: post #25

I am curious. As I understand it, both RISC and CISC processors are implemented in microcode for the actual hardware gates on the chip. And perhaps different hardware generations make it easier to build different micro-code machine architectures. So why not just offer an instruction set that matches the base hardware architecture? Rather than have all that decoding done on the chip, why not by a compiler? I understan…

It turns out sufficiently advanced compilers are hard to write (see: Itanium)

Re: RISC vs. CISC: The Post-RISC Era (1999)

#29

Post by almost » Thu, Jan 05, 2023, 1:58 PM UTC

fastaguy88 wrote: post #25

I am curious. As I understand it, both RISC and CISC processors are implemented in microcode for the actual hardware gates on the chip. And perhaps different hardware generations make it easier to build different micro-code machine architectures. So why not just offer an instruction set that matches the base hardware architecture? Rather than have all that decoding done on the chip, why not by a compiler? I understan…

I think that comparability is usually pretty important. You want want a cpu that your existing compiled programs will run on. Also compiler support, if every new revision required a new instruction set then all the compilers out here would need updating each time. I believe instruction decoding is pretty damn fast (and pipelined too!)

Re: RISC vs. CISC: The Post-RISC Era (1999)

#30

Post by kllrnohj » Thu, Jan 05, 2023, 1:58 PM UTC

klelatti wrote: post #17

msla wrote: post #15

Earlier quoted context omitted.

The Itanium was an interesting design and it wasn't even Intel's originally; Intel got in on HP's design, and HP was trying to leapfrog the superscalar designs by making parallelism the responsibility of software, akin to how the MIPS had made handling aggressive pipelining the responsibility of software: The Itanium design was to encode multiple instructions in very long instruction words, where all of the instructi…

> They are simpler to decode and execute, which is nice if you're making a small, cheap core aiming at low power consumption. Yes and there is an interesting corollary that it makes a big.LITTLE type arrangement more effective.

Except none of the shipping big.LITTLE implementations are "RISC" under the framework of the article, though. ARM is very definitely post-RISC and has very CISC-y features. Apple's versions go even farther and include x86 compatibility modes, very CISC-Y. And if course Intel's x86 is never accused of being RISC, either.

And really the entire reason big.LITTLE even exists at all is because the cores got too large and complex. Or, alternatively, they got too "CISC-y". So big.LITTLE is therefore about shipping a "CISC" and "RISC" core on the same piece of silicon really.