Talk:Reduced instruction set computer/Archive 1

This is an archive of past discussions about Reduced instruction set computer. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

This is the best article I have ever seen on wikipedia

This article explains the subject sooooo well, if only more math and science and articles can be this clear, especially in expounding the history and reasoning behind a development or innovation.

(Following is by a different reader:)

Indeed, it is truly first-rate; I called up the Talk page specifically to say so. My background includes superb instruction in computer basics (discrete-component DTL, up through basics of assemblers). Was a midnight hacker in 1960 on the BMEWS DIP* at the NORAD COC before the COC went under Cheyenne Mountain. Later, I was an associate editor at Electronic Design magazine, so I do know whereof I type! :0 *The machine for which I received such training

Not only is the content superb and apparently comprehensive, the author is as literate as the New Yorker magazine; it's a joy to read.

Best regards, Nikevich (talk) 01:12, 19 January 2010 (UTC)

Useful background in Berkeley RISC

There's a lot of useful, general info on RISC in that article. Merge some of it, maybe? MOXFYRE (contrib)

Diminishing benefits

I removed: "Compilers have also become more sophisticated, and are better able to exploit complex instructions on CISC architectures"

It would be hard to say the contrary of the first part of the sentence. But it is the contrary of the whole sentence that is actually true:

It's far much difficult to make a good compiler for RISC than for CISC.
The main trick with RISC-CISC is that with RISC, all what can be done +before+ execution time, is done by the +compiler+.
With CISC you have almost human readable code in that it's not miles from what you would expect it to be.
For instance with RISC you (the compiler in fact), have to reorder the instruction flow +before+ giving it the the pipeline. With CISC it's done by the processor.

Darkink (talk) 10:42, 5 June 2009 (UTC)

The points you listed above are not really true, where did you get them from?? -- Raysonho (talk) 14:50, 5 June 2009 (UTC)

Archiving

Does anyone object to me setting up automatic archiving for this page using MizaBot? Unless otherwise agreed, I would set it to archive threads that have been inactive for 60 days.--Oneiros (talk) 13:09, 18 December 2009 (UTC)

This talk page does not have a whole lot of activity. I'd put in 180 days.--Anss123 (talk) 13:48, 18 December 2009 (UTC)

O.K. And the last four threads will be kept.--Oneiros (talk) 15:52, 18 December 2009 (UTC)

Wording

I see a number of problems in the following sentence:

"Uniform, fixed length instructions with arithmetics restricted to registers were chosen to ease instruction pipelining in these simple designs, with special load-store instructions accessing memory."

"Uniform" appears do be redundant with "fixed length".

"Uniform" aims at the uniform and regular encodings in the first, very simple, RISC designs. /HenkeB 83.255.35.100 (talk) 16:20, 2 February 2010 (UTC)

The passive "were chosen" is bad style.

I find precise aiming and semantics more important than nice wording (and I fail to see the problem with passive forms). 83.255.35.100 (talk) 16:20, 2 February 2010 (UTC)

It is not clear what "to ease instruction pipelining" really means and why it is important.

The original Uniform, fixed length instructions with arithmetics restricted to registers were chosen to ease instruction pipelining in these simple designs, clearly suggests that these restrictions were deliberately accepted in order to make it easier to design a tightly pipelined CPU implementation. However, "making instruction pipelining significantly more efficient" is another, totally different claim. The wording seem to imply that the RISC-restrictions makes pipelining "more efficient" by some law of nature, which is untrue. 83.255.35.100 (talk) 16:20, 2 February 2010 (UTC)

The sentence describes what makes RISC designs simple but the wording suggests that they were simple to begin with.

They were simple to begin with. Early RISC designs, such as the IBM 801, were similar to the fast and simple execution engines within many microcoded "CISC" processors. 83.255.35.100 (talk) 16:20, 2 February 2010 (UTC)

There are no combined "load-store" instructions, just separate load instructions and store instructions.

Is this a deliberate misunderstanding? 83.255.35.100 (talk) 16:20, 2 February 2010 (UTC)

There is nothing "special" about ordinary load and store instructions.

In a classic RISC these are the only instructions that cannot be started every cycle, that's special. 83.255.35.100 (talk) 16:20, 2 February 2010 (UTC)

To fix these problems, I modified the sentence as follows:

"In these simple designs, most instructions are of uniform length and arithmetic operations are restricted to CPU registers, making instruction pipelining significantly more efficient, with separate load and store instructions accessing memory."

This wording seems much clearer to me but it was reverted, creating some collateral damage, with the comment, "original wording was better (more precise aiming, semantically)." I cannot follow this reasoning. Maybe the editor could elaborate? --EnOreg (talk) 09:47, 28 January 2010 (UTC)

Hi, thanks for your comments. Technically I agree with most of what you're saying. It's just that the original sentence didn't convey it--certainly not clearly. I've revised the new sentence, trying to incorporate your criticism. I still think there is some weirness left in the first paragraphs, e.g., the reference to some sophomore definition and the unexplained claim that the concept is an "old idea." What do you think? Cheers, --EnOreg (talk) 23:59, 7 February 2010 (UTC)

Improvement in the see also section

I suggest that the line "NISC" and "One instruction set computer" be merged, for the refer to the same thing. —Preceding unsigned comment added by 122.161.131.154 (talk) 10:35, 3 April 2010 (UTC)

RT is slow?

my impression is that the RT was as fast as anything comparable at the time; it would kick MicroVAX II butt and the MicroVAX I back to the last decade — Preceding unsigned comment added by 72.193.24.148 (talk) 01:40, 16 December 2011 (UTC)

RISC and x86 section seems biased

The "RISC and x86" section seems to be written simply to bash the x86 architecture. It needs to be more unbiased, and cite more sources. Also, the section about ARM-based processors now emerging is outdated. There are many ARM-based products on the market now. — Preceding unsigned comment added by 24.236.74.213 (talk) 01:31, 1 February 2012 (UTC)

I'm not sure how a section that says:

a lot of software is in x86 binary form, so new instruction sets couldn't replace it (one might consider it bashing to list market realities as one of the reasons for the continued success of an architecture, but it's true nevertheless);
companies implementing the x86 ISA threw transistors at the problem, so x86 processors caught up to RISC processors (true, and I'm not sure how it's bashing x86);
more of the previous point (with the same comment);

bashes the x86 architecture. Perhaps it needs more sources discussing the implementation techniques used to speed up x86, but I really don't see the bias there.

As for ARM-based products, I guess the question is which ones to include? The ones that more or less directly compete with x86-based PCs, or the ones in different markets that can in some cases substitute for traditional desktop/notebook PCs? The latter are already covered under "Expanding benefits for mobile and embedded devices". Guy Harris (talk) 01:46, 1 February 2012 (UTC)

In response to the IP above, this is not a terrible article, but is no gem either. The x-86 debate will probably be looked at as biased which every way one writes it. And we should remember that it is not always inherent architectural advantages, but who happened to be working on what at Intel, etc. Some of it is a people issue rather than an inherent design issue. So no need to get over worked on that.

Other items: The RISC success stories should certainly emphasize SPARC more - it started an entire server industry. The history is far, far too favorable to the 1960s nostalgia. The CDC 6600? Are we kidding? The 801 could have been called the first attempt and it only materialized in 1980. So the history section is just inaccurate. The Cray joke is funny, but unfortunately not quite right. Cray always took very clever (indeed genius) advantage of specific situations, but did not design the RISC philosophy.

So overall I would say this is an "ok" article, has some errors, but is not as bad as the software abominations we see in WikiProject Computing.

Finally should give a sense of speed and mention that some early supercomputers are now outrun by the iPads shipping now. History2007 (talk) 15:26, 20 March 2012 (UTC)

RISC OS?

I wonder whether RISC OS is worth linking from here as a 1980s example. 86.164.246.89 (talk) 01:07, 13 September 2013 (UTC)

As an example of what? OSes that run on RISC-based computers? There are plenty of those - SunOS (SPARC), HP-UX (PA-RISC), AIX (POWER, PowerPC), etc.). If you want an example of a RISC-based computer, that'd be Acorn Archimedes, not RISC OS. Guy Harris (talk) 01:21, 13 September 2013 (UTC)

And, of course, RISC/os (MIPS). Guy Harris (talk) 01:25, 13 September 2013 (UTC)

Return of CISC with effectively unlimited transistors?

At the moment, we have reached about the maximum clock speed possible (~4 GHz). There is also a concern about power consumption. However, costs per transistor continue to fall, and there is almost no restriction on numbers per chip. So, is there now a case for a hybrid CISC where the instructions are very powerful but still operate in a single cycle, by means of additional logic-gate complexity? For example, an entire C-function such as strtol() could be implemented in raw hardware in one cycle. — Preceding unsigned comment added by 82.10.237.122 (talk • contribs) 17:15, 25 November 2014‎

long
foo(void)
{
    char bigarray[1048572+1];
    int i;

    for (i = 0; i < 1048572; i++)
        bigarray[i] = '0';
    bigarray[1048572] = '\0';
    return strtol(bigarray, NULL, 10);
}

might be a little difficult to do in one cycle.

However, an instruction that processes 8 bytes of ASCII characters, ignoring a non-digit byte and everything after it, computing a polynomial value with power-of-ten coefficients based on the digit values, and returning the value and an indication of how many digits were processed, could possibly be done in one cycle, with that used as part of an implementation of `strtol()`.

But a processor with an otherwise-RISCy load-store architecture and with a three-argument "strtol" instruction, in which a 0-8 character string in one register is processed, with the polynomial value put in another register and the digit count put in a third register could still be considered RISCy. A number of RISC architectures have various flavors of SIMD instructions, and a "strtol" instruction could be viewed as somewhat SIMDish, although instead of processing each byte independently, the bytes are combined into a single result. Guy Harris (talk) 02:35, 26 November 2014 (UTC)

Locked In ?

The article says users of "PC" were locked into intel x86. However C compilers compiled code that had run on risc machines. x86 has emulators. CPUs with the feature of uploading new microcode came on the market long ago. i think "locked in" is a bit strong - never really true. — Preceding unsigned comment added by 72.209.223.190 (talk) 03:56, 14 July 2015 (UTC)

A C compiler doesn't help if:

your code isn't written in C (applications for DOS/Windows were also written in assembler, Turbo Pascal, etc., and DOS and (non-NT) Windows themselves had a significant amount of assembler code);
your code assumes it's running on a little-endian processor, or a processor that doesn't require strict alignment of data;

etc., so a C compiler for your instruction set is not a magic bullet. Yes, there were x86 emulators, but that didn't manage to make, for example, Alpha able to compete with x86.

And "the ability to upload new microcode" isn't the same thing as "the ability to run arbitrary instruction sets well", if that's what you're trying to say with "CPUs with the feature of uploading new microcode came on the market long ago." Most RISC CPUs didn't even have microcode, so it's not as if they could be microcoded into running x86 well, and even most microcoded CISC CPUs have instruction fetch paths that are rather oriented towards executing a particular instruction set. Guy Harris (talk) 07:01, 14 July 2015 (UTC)

History - What about ARM?

The article describes the history of the MIPS and SPARC processors in the early 1980s, but what about ARM, which was being developed around the same time?

The ARM (at the time an abbreviation of Acorn RISC Machine) project began in 1983 and the first silicon was delivered in 1985. In 1987 a PC containing an ARM processor was sold under the name "Acorn Archimedes".

It seems to me to be worth mentioning ARM's part in the history of RISC, coming at it from a different angle - much lower-end chips than SPARC and MIPS, which were destined for workstations. Since ARM's designs have since become ubiquitous, I think they are worthy of a greater mention than they get in this article. Marchino61 (talk) 00:10, 4 July 2016 (UTC)

Article improvements

In view of the above, I wrote a couple of quick missing articles on load/store vs register/memory architectures etc. that needed to be linked from here. I also fixed the lede. I think the best way to fix the article now is to use a "reduced diversion approach" and just state the basic elements in fully sourced form.

I will start by reducing the history discussions to the basics, add sources etc. and move it upfront. Then discuss the motivation, compilation issues, etc. and eventually work up to the mobile issues etc.

But mobile RISC is not the whole story and the article should also point out that RISC is not just for cell phones and the 8 petaflops K computer (fastest on the TOP500 as of this writing) also uses the SPARC64 - a RISC architecture. So RISC now dominates the low ground in cell phones and some of the high ground on the TOP500. That will shed light on the flexibility of the architecture.

Anyway, I will begin the fixes and move sections according to that plan. If there are suggestions, just post below here and we can discuss it. Thanks. History2007 (talk) 12:58, 21 March 2012 (UTC)

It would be nice if the history of RISC also mentioned that other RISC product from the other side of the pond: ARM. John Allsup (talk) 00:26, 24 April 2013 (UTC)

Just Do It. Guy Harris (talk) 01:01, 24 April 2013 (UTC)

ROMP a single-chip 801?

The article says "The 801 was eventually produced in a single-chip form as the ROMP in 1981, which stood for 'Research OPD [Office Products Division] Micro Processor'." The documents "The 801 Minicomputer - An Overview" and "System 801 Principles of Operation" describe a machine with 24-bit registers, but the "RT PC Technical Reference, Volume 1" describes a machine with 32-bit registers. Was there a later machine in the 801 family that looked like the ROMP? Guy Harris (talk) 01:03, 22 March 2012 (UTC)

I really do not remember the details of the 801 family follow ups now - it was long ago... Is there an error in what the article says? I do not see one. The Jurij Šilc reference I looked up for the 801 only refers to the 32 bit. They may have played with a few systems, I am not sure now. But just fix it if you see an error. Thanks. History2007 (talk) 01:27, 22 March 2012 (UTC)

By the way, the Wikipedia ROMP article (which happens to be reference free) says: "The original ROMP had a 24-bit Reduced Instruction Set Computer (RISC) architecture developed by IBM, but the instruction set was changed to 32 bits a few years into the development." So that may be the case, but that is probably too much detail for this article given that the 801 did not go that far on its own. History2007 (talk) 02:04, 22 March 2012 (UTC)

I was asking a question, not making an assertion; not having been in IBM Research or in the group(s) that did ROMP, I don't know what the full history of the 801 or ROMP was. I've asked in the ROMP article for some citations; more history on the 801 and ROMP would be interesting (but might require help from somebody who was inside IBM at the time). Guy Harris (talk) 07:05, 22 March 2012 (UTC)

Ok, no problem. But the ROMP article itself needs serious help and I will hence not even look at it again so I will not even be tempted to fix it. I did not even want to fix this one until some user shifted the tags etc. So I will do my best not to think of ROMP, at a time when Processor register needs so much more help.... I posted for help on WikiProj computing about this page and Processor register, but I am not holding my breath that it will get fixed soon that way... History2007 (talk) 08:18, 22 March 2012 (UTC)

iPad, but not smartphones?

The article says "In the 21st century, the use of ARM architecture processors in the Apple iPad provided a wide user base for RISC-based systems." Is the idea here that the iPad (and, potentially, other ARM-based tablets, depending on the success of, for example, Android or Windows 8) are more like "real computers" than smartphones are, so people are more likely to think of them as "computers"? Guy Harris (talk) 01:05, 22 March 2012 (UTC)

Reasonable comment actually. Shows that I don't think of cell phones as real computers. Please fix that to represent the views of the modern generation for whom cell phones are computers. But the general idea is that RISC now runs $800 computers to $80 million systems. That is the message. History2007 (talk) 01:30, 22 March 2012 (UTC)

I have now done a first set of fixes to the lede and the first section, added refs, etc. and will take a break. So please check that, fix items, etc. Thanks. History2007 (talk) 01:48, 22 March 2012 (UTC)

Anyway, I fixed it now so it says smartphone as well. History2007 (talk) 08:39, 22 March 2012 (UTC)

Design Philosophy and Berkeley RISC Article

Reading through the article, I didn't find it adequately answered questions like "Why was RISC designed?", "What problem(s) did it solve, and what was conceived to solve the problem(s)?"

I expected these questions would be answered in the "Instruction Set Philosophy" section, but it headlines by stating that RISC isn't a dumb idea, even though the acronym includes the word "reduced". The "Instruction Set Philosophy" section fails at describing the RISC "Instruction Set Philosophy" to people lacking prior knowledge of RISC. The best information I found about RISC on Wikipedia was in the "RISC Concept" section of the Berkeley RISC article. But that section of the article links back to this one as the main article. This is a problem because it contains plenty of information that this article does not, however, without references (at least not with any inline citations). On the talk page of the Berkeley RISC article, there is discussion about removing the "RISC Concept" section of that article because it "is most probably redudant" with this article, but again, this is not true. If references for that information can be found, that information should be moved to this article and a less in-depth summary written for the Berkeley RISC article. I don't yet possess an adequately comfortable working knowledge of RISC or Berkeley RISC to volunteer for this duty, but I hope someone can find my observations useful. Wurtech (talk) 18:18, 27 February 2017 (UTC)

Requested move 10 May 2017

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Moved.Granted as a non-controversial request.(non-admin closure) Winged Blades^Godric 05:56, 19 May 2017 (UTC)

Reduced instruction set computing → Reduced instruction set computer – This article was moved here from its previous title at Reduced instruction set computer on 20 April 2010 without any prior discussion to seek consensus. The only rationale was given in the edit summary: "intruductory [sic] paragraph's wording is awkward and more easily addresses RISC as an architecture ("… computing") than an instance of it's use ("… computer")."

I contend that this is incorrect. Whatever compositional problems the lead had, the solution cannot be to represent this topic as being called "reduced instruction set computing" when it is not. To do so would be to misrepresent the topic and what the topic is commonly called, thus introducing factual inaccuracies. The term "RISC" was introduced in David Patterson and David R. Ditzel's "The case for the reduced instruction set computer" (ACM SIGARCH Computer Architecture News, V. 8, No. 6, October 1980). Since then, that is what RISCs have been called. The idea that using "computing" instead of "computing" creates a distinction between "architecture" and an instance of its use is incorrect. The use of "computer" instead of "computing" in RISC is no different to that in terms such as "stored-program computer". One does not see instances of "stored-program computing". 50504F (talk) 07:23, 10 May 2017 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

What about PowerMacs using PowerPC processors from IBM for many years, G3, G4, G5...

It seems the article is not mentioning probably the biggest user of RISC processors, APPLE. In the 90s all Macs were powered by IBM RISC PowerPC processors, then the transition to Intel happened in the early 2000s... — Preceding unsigned comment added by 193.105.48.90 (talk) 13:37, 6 June 2017 (UTC)

Article implies performance parity with x86 throughout without providing data to back up that claim

This article repeatedly makes the reader believe there is performance parity between RISC and CISC computers, forcing itself to take a very ignorant look at computing as a whole in order to accomplish that goal. For example...

"The term "reduced" in that phrase was intended to describe the fact that the amount of work any single instruction accomplishes is reduced—at most a single data memory cycle—compared to the "complex instructions" of CISC CPUs that may require dozens of data memory cycles in order to execute a single instruction.[24]"

Despite the complexity of CISC instructions, modern CISC computers can execute between 3-4 IPC (instructions per cycle). Source: https://lemire.me/blog/2019/12/05/instructions-per-cycle-amd-versus-intel/

If we look at the manual for a common RISC CPU like the SiFive E21, we can see that..... “The pipeline has a peak execution rate of one instruction per clock cycle.” Source: https://sifive.cdn.prismic.io/sifive%2Fc93c6f29-5129-4e19-820f-8621300eca53_e21-core-complex-manual-v19.05.pdf

So despite having less complex instructions, RISC processors in practice still can't execute more instructions than their CISC counterparts. Additionally, CISC computers don't have to "translate" or "emulate" 90% of the code in existence. So they have the home-field advantage over RISC which must waste clock cycles to emulate the x86 instruction set. The emulation of x86 software is not a value-added feature of CISC to the user. It is a non-value-added feature that only exists to enable the CPU to do work most existing CISC computers can do natively.

Please modify the article to at least acknowledge the substantial performance difference between CISC and RISC. Also, please refrain from seeking to marginalize the substantial technological benefits of using CISC technology. I understand this is a RISC article, but it's disingenuous to represent RISC as an apples-to-apples comparison to CISC. It clearly isn't. You have the entire "energy efficiency" soap-box to stand on but you choose not to use it. Instead you stand on the performance soap-box trying to sell CISC-like capabilities under the RISC flag while somehow ignoring the fact that CISC still exists, and is still actually still more performant than RISC. Source: https://images.idgesg.net/images/article/2020/12/m1_cinenbench_r20_nt-100870777-orig.jpg — Preceding unsigned comment added by 2603:3005:3C77:4000:5DA2:1427:DC1C:5DE5 (talk) 19:28, 1 January 2021 (UTC)

So what about other RISC CPUs such as the POWER9 or the Apple M1? The execution unit of the SiFive E21 is, as the manual you cite says, "a single-issue, in-order pipeline"; you're not going to get maximum raw performance from that. The POWER9, however, is a superscalar out-of-order processor; the IEEE Micro paper on it says "Variants of the core support completion of up to 128 (SMT4 core) or 256 (SMT8 core) instructions in every cycle." I don't know whether any articles on the M1 are out yet, but this Anandtech article is looking at the Apple A14 as an example of what Apple's ARM chips' microarchitectures are like these days, and the A14 is another superscalar out-of-order processor.

"RISC vs. CISC" is a somewhat bogus comparison. Any modern RISC processor should be able to outrun that boring old single-issue, in-order 80386 CISC processor, but that's like saying a modern Ford could outperform a Model T - not very interesting. Comparing an x86 processor intended for desktop/notebook or server use with a 32-bit embedded processor is also not very interesting. If you want to compare Intel and SiFive, try comparing a Xeon with, say, a U84, which is a 64-bit superscalar out-of-order processor, just like current Xeons.

And, "Additionally, CISC computers don't have to "translate" or "emulate" 90% of the code in existence." notwithstanding, I can think of at least one CISC processor that would have to translate or emulate x86 code. Presumably what you meant is "x86-based computers don't have to translate or emulate 90% of the code in existence", so that part isn't comparing CISC with RISC, it's comparing x86 with various RISC instruction sets.

The extent to which that's a "home-field advantage" for a particular market depends on the effort involved in moving code from x86 to another instruction set. If we look at current CISC architectures, we have x86 and System/3x0, where I'm including x86-64 as part of x86 and z/Architecture as part of System/3x0.

For x86, it's currently mainly used in Windows desktops, notebooks, and servers, in Linux servers, and in Apple desktops and notebooks. For the latter, Apple have a porting guide, where the main issues they mention are:

Apple's processors not having a strong memory-ordering model, so you have to be a more careful when sharing data between threads;
"Cheating the compiler" by having a function defined with a fixed argument list and declared as having a variable argument list (and an Objective-C equivalent);
some cases where various named constants have different values on different instruction sets;
using assembler-language code or platform-dependent vector instructions;
making an unsupported assumption about the return value of mach_absolute_time();
some differences in float-to-int conversions;
software that generates machine code on the fly.

A number of vendors have already fixed their code and are offering both x86-64 and ARM64 binaries (or, rather, binaries that include code for both instruction sets. I can testify, from working in the Core OS group at Apple when the PowerPC -> x86 switch was done, that the code I dealt with didn't need much work (but then I already knew about byte order from my days at Sun, with the big-endian 68K-based and SPARC-based machines and the little-endian Sun386i; that was one of the bigger issues in that transition, but isn't an issue going to little-endian ARM).

For Linux, a lot of software is part of what the OS vendor provides in packages, and that's largely reasonably portable code in C or C++, or code in various scripting languages where the interpreter *itself* is portable.

I can't speak for the Windows world, but at least some of that software may require little if any effort to port to ARM64.

As for translating or emulating, at least for some software, Rosetta 2 seems to do a decent job of translating.

So the home-field advantage might not be as large as you'd like it to be.

(For System/3x0, either the code is running on an IBM operating system for S/3x0, in which case the OS hasn't been ported to any other platform, so you can't move it, even to another CISC platform, too easily, or it's running on Linux, in which case see above - typical code moves there are probably from x86-64 to z/Architecture.)

As for the Cinebench results, if we look at some Cinebench R23 single-core results, the M1 doesn't do too badly. For the multi-core results, note that only four of the M1 cores are high-performance cores; it's interesting that it's in the same range as a group of 6-core Intel and AMD processors, where all the cores are presumably identical, so if the low-power cores count as half a high-performance core, that'd make an 8-core M1 the equivalent of a 6-core all-high-performance version. It will be interesting to see if Apple comes up with all-high-performance-core versions for desktop machines, and how well they do.

Bottom line:

There's CISC and there's x86, which is one example of a CISC processor, but isn't the only one that's ever existed or even the only one that currently exists.
Assumptions about RISC or CISC processors that may have been true in the early days of RISC don't necessarily apply now; for example, the P6 microarchitecture showed how to make at least some CISC processors do a good job of superscalar out-of-order processing ("some" doesn't just mean x86 - newer z/Architecture processors apparently do the same "break instructions up into micro-operations and throw them at the superscalar OOO execution unit" stuff), and high-performance RISC and CISC chips both have a ton of transistors.
The article should probably be updated to reflect current reality - where "current reality" not only includes the now 25-year-old superscalar OOO micro-operation processor work, but also various current ARM processors, which are currently the only RISC processors that I know of that cover as wide a range of applications as x86 processors (they both go from laptops to servers and supercomputers, with ARM going below that to smartphones).
The article shouldn't be an advocate for either type of instruction set. Guy Harris (talk) 22:00, 1 January 2021 (UTC)

Oh, and 5. CPU performance isn't the only contribution to system performance.

If we look at the November 2020 TOP500 supercomputer list, the top four machines have RISC CPUs - an ARM64 machine at the top, with two Power ISA machines below it, and a Sunway SW26010 machine below that, with the fifth using AMD Epyc processors. However, the two Power ISA machines and the Epyc machine have Nvidia GPUs as accelerators, so how much of the difference is due to CPU differences rather than GPU differences - or interconnect differences - is another matter. Guy Harris (talk) 22:39, 1 January 2021 (UTC)