Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

51–57 of 57 posts

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

#51

Post by sweetjuly »

kllrnohj wrote: post #24
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?

I feel that this is a common understanding of RISC but not a particularly useful one because not all complexity is equal.

Things like matrix extensions are "complicated" from a perspective of "there are a lot of instructions that do weird specific things" but, critically, none of these operations are particularly hard to do in hardware. For example, a fixed size matrix multiply is something that the highly parallel nature of hardware is especially well suited for. This greatly contrasts with truly CISC instructions like the VAX's polynomial multiply which effectively just became a massive microcode subroutine because hardware couldn't implement it well either.

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

#52

Post by Thetawaves »

msla wrote: post #15
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 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…

> This removes the need for the hardware to do reordering, and shoves the responsibility for finding parallelism onto the human or compiler, both of which can, presumably, take a more global view of the problem than a piece of silicon can.

I think this was proved wrong - the opposite is true; it is incredibly difficult for software to predict the internal state of a CPU at compile time. The silicon is truly the only thing with an accurate account of its internal state ( cache, register renaming, etc ).

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

#53

Post by Animats »

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.

> They are simpler to decode

One of the big headaches with x86 superscalar machines is that finding the instruction boundaries is hard. The decoders, looking ahead, may guess at alignment and decode bytes which represent a totally bogus instruction, which causes work that gets discarded further downstream. Intel and AMD did this very differently in the early days of superscalar.

If you're going to have a variable length instruction set, it would be nice if it worked like UTF-8, where you can start anywhere in a stream and get aligned within a few bytes. x86 is not like that.

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

#54

Post by socialdemocrat »

pjc50 wrote: post #18
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

Tilera tried that, I see they are now out of business. https://en.wikipedia.org/wiki/Tilera As others have pointed out, it makes your memory latency problems worse, not better. It's the equivalent of "beowulf cluster of raspberry pi's".

The core count of Tilera CPUs is totally normal today, so not exactly a failed idea. AMD Ryzen thread piper has 64 cores and if you count number of hardware threads you got 128. That is more than Tilera had. AMD is a very successful company. You got also got Ampere Computing with the Altra Max with 128 cores. Anyway these are all cases of CPUs for general purpose computing while the 1000 core RISC-V CPU was really a specialized system for AI acceleration and scientific computing not general purpose computing.

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

#55

Post by socialdemocrat »

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.

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?

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

#56

Post by socialdemocrat »

kllrnohj wrote: post #24
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?

No, that is not the case. RISC-V was designed to work both in embedded systems, workstations, supercomputers and specialized hardware. That is why the instruction-set is made modular. It is allow you to tailor the chip to very different types of hardware.

The extension system is exactly why I would call RISC-V the return of RISC. It is what allows you to keep the CPU significantly simpler because you only add what you need for the system you are designing.

For instance if you want really strong vector processing capability you can design very small cores with only vector processing instructions and the most necessary scalar operations. All the stuff you need typically to run a multi-user OS (handle privilege levels) can be thrown out.

That is exactly what Esperanto Technologies doing. They got got four fat Out-of-Order cores with all the instructions you typically would want in a modern CPU running Linux, while there are 1088 small in-order cores with support for RISC-V vector extension. Vector processing actually adds very few transistors if the core is in-order rather than out-of-order.

I would say this is all quite RISCy in that you are making simple tailor made chips rather than making huge complex monoliths to do everything, which is the CISC way IMHO.

Intel btw is realizing their approach was kind of dumb when then tried making their big-little core design. To keep the small cores small they had to throw out the complex AVX-2 instructions.

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

#57

Post by klelatti »

kllrnohj wrote: post #30
klelatti wrote: post #17

Earlier quoted context omitted.

> 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…

> So big.LITTLE is therefore about shipping a "CISC" and "RISC" core on the same piece of silicon really.

You're mixing up ISA and implementation. To the extent that RISC / CISC has any meaning at all any more it's a property of the instruction set. RISC-V which makes a big deal out of being RISC is after all just an ISA. And I take issue with the original article on this too.

Post reply on HN