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

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

#31

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

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…

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

I believe you are describing VLIW architecture here? Is that correct?

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

Interesting. How exactly does a VLIW architecture remove the need for reordering? Is it just that any instructions in a word mean automatically mean there's no dependencies in that long instruction? Was that the original intention of VLIW?

I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point?

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

#32

Post by relaxing » Thu, Jan 05, 2023, 2:03 PM UTC

mardifoufs wrote: post #8

ryao wrote: post #5

> [Editor's note: this example actually finds 20^4, not 20^3. I'll correct it when the load on the server goes down. Still, it serves its purpose. I guess the load on the server has yet to abate for 24 years.

Wait, why would he need to wait for the load to go down before making a change? What am I missing, was it normal back then?

It's possible if there was so much load on the server (traffic from Slashdot?) he couldn't telnet in or open an FTP session to change the HTML.

/. post: https://tech.slashdot.org/story/99/10/21/0848202/risc-vs-cis... 119 comments wasn't considered doing big numbers then. Note someone does call out the Cube issue. No upvotes.

However, in this case it doesn't make much sense - he was changing the file anyway by putting in the "editor's note", with a lot of fancy formatting to boot.

My guess is the author was being cute in writing an acknowledgement of the mistake rather than fixing it silently.

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

#33

Post by leeter » Thu, Jan 05, 2023, 2:09 PM UTC

bogomipz wrote: post #31

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…

>"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. I believe you are describing VLIW architecture here? Is that correct? >"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…

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point?

The answer is: yes

Itanium failed because getting instruction parallelism is actually incredibly hard to do and compilers didn't catch up in time to make it matter. But it also failed because of AMD64 which had backwards compat, was cheaper by a lot, and was a lot easier to get decent perf out of.

Opinion: I think Itanium was always destined to fail. The idea seems good on paper but fails in practicality because it limits what the hardware can do to achieve speed without breaking backwards compat with itself. You can't have a superscalar Itanium by definition because branch prediction etc. is by design delegated to the compiler. This means that the chips can literally only go up via clock speed, which as we now know doesn't scale forever.

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

#34

Post by relaxing » Thu, Jan 05, 2023, 2:15 PM UTC

googlryas wrote: post #9

mardifoufs wrote: post #8

Earlier quoted context omitted.

Wait, why would he need to wait for the load to go down before making a change? What am I missing, was it normal back then?

It might invalidate a bunch of caches and increase load even more.

Ars might have been running Squid back then, but I kind of doubt it. They weren't that huge of a deal.

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

#35

Post by kllrnohj » Thu, Jan 05, 2023, 2:24 PM UTC

googlryas wrote: post #9

mardifoufs wrote: post #8

Earlier quoted context omitted.

Wait, why would he need to wait for the load to go down before making a change? What am I missing, was it normal back then?

It might invalidate a bunch of caches and increase load even more.

Wouldn't putting that editor's note there also have done that?

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

#36

Post by pjmlp » Thu, Jan 05, 2023, 2:25 PM UTC

pjc50 wrote: post #19

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…

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

Connection Machine showed otherwise, just like HPC languages as Chapel.

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

#37

Post by jcranmer » Thu, Jan 05, 2023, 2:34 PM UTC

bogomipz wrote: post #31

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…

>"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. I believe you are describing VLIW architecture here? Is that correct? >"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…

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point?

It's closer to the truth to say that Itanium caused the world to become largely x86. In the 90s, while the personal computing market may have been dominated by x86, the workstation and server markets (which was the segment Itanium was targeting) was definitely a lot broader and competitive. HP canceled its own architecture line to focus on Itanium, and a couple of other architectures saw roadmaps dwindle because of it.

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

#38

Post by leeter » Thu, Jan 05, 2023, 2:39 PM UTC

jcranmer wrote: post #37

bogomipz wrote: post #31

Earlier quoted context omitted.

>"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. I believe you are describing VLIW architecture here? Is that correct? >"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…

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? It's closer to the truth to say that Itanium caused the world to become largely x86. In the 90s, while the personal computing market may have been dominated by x86, the workstation and server markets (which…

RISC Architectures confirmed murdered by Itanium: Alpha AXP, MIPS (on the desktop), and HP PA-RISC

Architectures set back significantly by Itanium: POWER, SPARC

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

#39

Post by zozbot234 » Thu, Jan 05, 2023, 3:36 PM UTC

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?

> Isn't RISC-V continually adding new complexity as it attempts to scale up

On the contrary, some extensions are pretty clearly designed for simplicity. For example the original 'M' extension implemented both multiply and divide insns, but it was found that the latter were not always useful and required large area. So a multiply-only extension was created. The basic set of integer instructions is the one thing that's anywhere close to immutable about "RISC-V", anything else is potentially open to replacement with something better, though of course with the cost of some incompatibility.

And actually, even the base set is not totally unchangeable as shown by the RV-E variant, halving the number of integer registers to 16.

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

#40

Post by zozbot234 » Thu, Jan 05, 2023, 3:44 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…

> So why not just offer an instruction set that matches the base hardware architecture?

That's pretty much what a VLIW is. The problem is, well, it matches the base hardware architecture. Any change at all in μarch means a full rewrite of any binary code you might ever want to run on the chip. The Mill folks (who are essentially doing a VLIW with lots of clever heuristics/tricks to try and extract more parallelism from the code, on par with mainstream out-of-order chips) are unusually clear about that. Part of the point of a generic ISA like RISC-V is to act as a layer of abstraction, and the "close to the metal" approach you're describing doesn't do that.