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

11–20 of 57 posts

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

#11

Post by Animats »

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 started executing more than one instruction per clock. Now RISC machines were behind in speed. So they had to become superscalar. That killed the simplicity. There was no longer any real point to pure RISC instruction sets.

(The author mentions the Itanium. That existed mostly because Intel wanted a patentable technology others couldn't clone. It was very original, and not in a useful way.)

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

#12

Post by Animats »

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.

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.

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

#13

Post by socialdemocrat »

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-philosophy-in-...

When John wrote that article RISC processors had gotten very complex. Then it was a lot about complex address modes. But the last decades complexity stems more from lots of SIMD instructions.

RISC-V has aimed to reverse that trend and create å significantly smaller ISA. The RISC counter-trend to complexity is thus still alive and kicking.

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

#14

Post by mananaysiempre »

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

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

#15

Post by msla »

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 instructions in a given word can be executed at once. 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.

A problem with that was, apparently, figuring out good parallelism statically wasn't enough to get the performance gains Itanium needed to be competitive

https://stackoverflow.com/questions/1011760/what-are-the-tec...

For example, Itanium struggled with the non-deterministic nature of memory latency

https://softwareengineering.stackexchange.com/questions/2793...

AMD iterating on x86 to produce AMD64 and giving x86 code a compatible path to the 64-bit world certainly didn't help Itanium's prospects, either.

Also:

> There was no longer any real point to pure RISC instruction sets.

They are simpler to decode and execute, which is nice if you're making a small, cheap core aiming at low power consumption.

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

#16

Post by nordsieck »

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…

> Then CISC microprocessors became superscalar, and started executing more than one instruction per clock. Now RISC machines were behind in speed. So they had to become superscalar. That killed the simplicity. There was no longer any real point to pure RISC instruction sets.

I thought DEC Alpha was always ahead in speed. At least until it got bought and mostly abandoned by Compaq and then HP. Or is Alpha insufficiently RISC?

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

#17

Post by klelatti »

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…

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

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

#18

Post by pjc50 »

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

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

#19

Post by pjc50 »

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…

> 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 the big lesson since, well, the LISP machine is that this doesn't really work. What does work is letting the programming languages evolve driven by user needs and back-filling technology to achieve the desired performance.

The average user performance experience on a webpage is standing on the shoulders of a lot of giants, and any performance increase that relies on climbing all the way down and then back up a different stack simply isn't going to get delivered. What people want is faster sequential execution at almost any cost.

There's also an important detail that the language can only know about instruction ordering statically, while the CPU can reorder instructions at runtime depending on exactly what's ready.

Post reply on HN