8 ms·
RISC vs. CISC: The Post-RISC Era (1999)
- dang 4y agoIt's a great submission, but please don't post archive links to HN when there's a live version of the original available. You're welcome to put the archive link in a comemnt; lots of people do that. We changed the URL from https://web.archive.org/web/19991129051550/http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html https://web.archive.org/web/19991129051550/http://arstechnic....
- xeeeeeeeeeeenu 4y agoSorry for that. At first I found a broken, unreadable version of the article[1] and I guess I assumed they don't have a better copy. [1] - https://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html https://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-1.htm...
- dang 4y agoNo worries! The Google doth not always deal the same results.
- rluoy 4y agoI really enjoy reading Jon's book, inside the machine.
- ryao 4y ago> [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.
- mardifoufs 4y agoWait, 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?
- googlryas 4y agoIt might invalidate a bunch of caches and increase load even more.
- relaxing 4y agoIt'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-cisc-in-the-post-risc-era 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.
- stefanpie 4y agoDuring 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 https://www.microarch.org/micro55/media/keynote_ditzel.pdf
- speed_spread 4y agoThe 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.
- Animats 4y agoRight. 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.
- klyrs 4y agoIndeed, a GPU is effectively a massive grid of RISC cores (and accessing global memory is a major bottleneck). I do think that "a GPU but RISCV" is an interesting proposal, but I doubt the major players would be willing to abandon their existing instruction sets
- mananaysiempre 4y agoIt’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.)
- Animats 4y agoThe 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.)
- msla 4y agoThe 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-technical-reasons-behind-the-itanium-fiasco-if-any 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/279334/why-was-the-itanium-processor-difficult-to-write-a-compiler-for 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.
- 4y ago
- socialdemocrat 4y agoInteresting 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-2022-fa871861bc94 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.
- kllrnohj 4y agoDoes 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?
- zozbot234 4y ago> 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.
- kllrnohj 4y agoReducing the register count is not a "RISC" move. It probably makes sense for the target die size of a given product, but it's definitely not something "RISC" related which was, at the time, about doing the exact opposite - increasing the register count relative to CISC CPUs. Similarly divide wasn't removed. It's still there. Instead a second extension was added that introduced multiply-only variants. Total complexity was increased, not reduced.
- drmpeg 4y agoDave 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 https://www.youtube.com/watch?v=5foT3huJ_Gg
- menaerus 4y agoTo 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.
- fastaguy88 4y agoI 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?
- leeter 4y agoTo 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.
- Macha 4y agoIt turns out sufficiently advanced compilers are hard to write (see: Itanium)
- almost 4y agoI 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!)
- zozbot234 4y ago> 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.
- Mountain_Skies 4y ago>RISC architecture is gonna to change everything. -- Acid Burn That line from the movie Hacker's elicited many "that didn't age well" comments in the years after the movie came out but ultimately proved to be correct. It just needed a long enough timeframe to happen.
- Sparkyte 4y agoAs more RISC and CISC architectures add more sets and extensions the more similar they become as they end up targeting each other's design challenges. Which makes architecture moot.