News RISC-V CPU runs The Witcher 3 at 15 FPS — 64-core chip paired with Radeon RX 5500 XT GPU deliver laggy gameplay

[Admin]

A modern AAA game like The Witcher 3 can now run on RISC-V architecture, albeit with minimal performance.

RISC-V CPU runs The Witcher 3 at 15 FPS — 64-core chip paired with Radeon RX 5500 XT GPU deliver laggy gameplay : Read more

 

[usertests]

I've played some games extensively at sub-30 on an old Llano APU.

This video looked pretty bad, especially with the stutters. But it's a start.

 

[NinoPino]

Absolutely good for a first try on a 2Ghz 64 core CPU with DDR4 3200 and a Radeon 5500 XT in FullHD.

 

[mac_angel]

I know the CPU would be the bottleneck, but I still can't help but wonder about a beefier GPU.
RISC came out a long time ago, and as far as I remember, it was far superior technology back then. Apple used them for a while, but at that time they were really struggling, too. I know RISC has evolved over the years, but I don't think it's evolved as much as X86 and X64 CPUs, which again, makes me wonder where they could have been now if they had have been.

 

[JamesJones44]

I wish Game devs would start to migrate to using Vulkan. Then supporting other OSs and CPU architectures becomes a lot easier. I know many have spent decades in DirectDraw and Direct3D, but I think cross platform tools are mature enough now that they really should be considered before using platform specific APIs.

 

[epobirs]

I know the CPU would be the bottleneck, but I still can't help but wonder about a beefier GPU.
RISC came out a long time ago, and as far as I remember, it was far superior technology back then. Apple used them for a while, but at that time they were really struggling, too. I know RISC has evolved over the years, but I don't think it's evolved as much as X86 and X64 CPUs, which again, makes me wonder where they could have been now if they had have been.

Apple uses it now. What do you think the R in ARM stands for?

 

[usertests]

I know the CPU would be the bottleneck, but I still can't help but wonder about a beefier GPU.
RISC came out a long time ago, and as far as I remember, it was far superior technology back then. Apple used them for a while, but at that time they were really struggling, too. I know RISC has evolved over the years, but I don't think it's evolved as much as X86 and X64 CPUs, which again, makes me wonder where they could have been now if they had have been.

Whatever you've heard about RISC in general a long time ago doesn't apply to some RISC-V cores running emulation today. A lot of RISC-V cores I hear about are weaker than Cortex-A55. Not sure about C920, but the clock isn't high and 64 of them aren't useful here. More importantly, the blog post explains that many RISC-V instructions were needed to implement some simple and widely used x86 instructions, leading to the low performance.

I looked into the GPU out of curiosity and found i7-4770 and RX 5500 XT running Witcher 3 "Next Gen", which I guess is more intensive than the original game. At 1080p High, it was around 60 FPS and bottlenecked by the GPU.

The Milk-V Pioneer has PCIe 4.0 x16, so no trouble there.

 

[Findecanor]

RISC-V is an extensible instruction set, with a small core and many extensions.
To run 64-bit Linux, you'd need the profile RV64GC, which still lacks vector, address calculation and bit manipulation: which were ratified only in the last few years, and would be needed for instruction feature-parity with ARM and x86.

The XuanTie T-Head 910 / 920 in the Milk-V Pioneer is a few years old and implements only RV64GC, a draft version of the Vector extension and T-Head's own proprietary extensions where many instructions can do the same as officially ratified extensions but using different opcodes.

Box64 running on the Milk-V Pioneer that we see here does not have support for T-Head's proprietary extensions. I think the developers are prioritising official extensions.

In other words: It is not running as fast as it will be.

 

[acadia11]

I know the CPU would be the bottleneck, but I still can't help but wonder about a beefier GPU.
RISC came out a long time ago, and as far as I remember, it was far superior technology back then. Apple used them for a while, but at that time they were really struggling, too. I know RISC has evolved over the years, but I don't think it's evolved as much as X86 and X64 CPUs, which again, makes me wonder where they could have been now if they had have been.

it's not a question of superiority but approach. RISC processors haven't gone anywhere, ARM is a risc processor, the point of RISC, is it reduced complexity, simplified cpu operations , and there for reduced implementation cost but more importantly reduced power consumption. CISC processors were more common because youi think x86 CPU's became popular and all those fancy instructions you take for example AVX-512 are quite popular and lot's of software started utilizing the advanced instruction / more complex optimized sets of x86 overtime. Of course, all those operations have a transistor and implementation cost, but x86 has come a nlong way in the power department with other tricks. But RISC is certainly as evolved it's always been around.

 

[The Historical Fidelity]

Apple uses it now. What do you think the R in ARM stands for?

The R in ARM stands for “reduced instruction set” which is a generic term for any microarchitecture that emphasizes barebones instructions (compared to x86 which is a “complex instruction set architecture”) that requires more advanced compilers to layout said instructions in a way that complex instructions are created in software. Reduced instruction set CPUs are greatly affected by the quality of the compiler used for the code being run.
By reducing the instruction set, the micro-architectures become less intricate because they can free up transistor space that used to be occupied by complex instruction decoders, translators, and hardware that enables legacy instruction support (dating back to the 1970’s for x86 so has a quite bloated instruction set where some instructions are rarely used nowadays) to be reallocated to improve IPC and power efficiency. This is the only reason why Apple’s M-series chips are faster clock-for-clock if not held back by inferior compiling.

 

[mac_angel]

Whatever you've heard about RISC in general a long time ago doesn't apply to some RISC-V cores running emulation today. A lot of RISC-V cores I hear about are weaker than Cortex-A55. Not sure about C920, but the clock isn't high and 64 of them aren't useful here. More importantly, the blog post explains that many RISC-V instructions were needed to implement some simple and widely used x86 instructions, leading to the low performance.

I looked into the GPU out of curiosity and found i7-4770 and RX 5500 XT running Witcher 3 "Next Gen", which I guess is more intensive than the original game. At 1080p High, it was around 60 FPS and bottlenecked by the GPU.

The Milk-V Pioneer has PCIe 4.0 x16, so no trouble there.

I understand about the emulation and such. My point was if things were NOT bound to the x86 and x64 architecture and an emulation wasn't required. And, along with that, if RISC had have had the same rate of maturity and advancement as the x86 and x64 CPUs such as Intel and AMD.
If RISC had have advanced as much as Intel and AMD, and PCs were more open source instead of needing those instruction sets (yes, I know they are required for the type of programming, not my point). Basically, if RISC had have been able to advance as much as Intel and AMD, and were all on an equal playing field. And, I know it was a long time ago and my memory is definitely not as great as it once was, but I do remember people saying that RISC was a superior technology back then.

 

[mac_angel]

it's not a question of superiority but approach. RISC processors haven't gone anywhere, ARM is a risc processor, the point of RISC, is it reduced complexity, simplified cpu operations , and there for reduced implementation cost but more importantly reduced power consumption. CISC processors were more common because youi think x86 CPU's became popular and all those fancy instructions you take for example AVX-512 are quite popular and lot's of software started utilizing the advanced instruction / more complex optimized sets of x86 overtime. Of course, all those operations have a transistor and implementation cost, but x86 has come a nlong way in the power department with other tricks. But RISC is certainly as evolved it's always been around.

Interesting, but I probably sucked at explaining my train of thought here. If RISC was on an equal playing field (like, say, it had have licensed those instruction sets, or the instruction sets weren't needed); if RISC was able to advance at the same degree as Intel and AMD, I wonder where they'd be now.

 

[NinoPino]

The XuanTie T-Head 910 / 920 in the Milk-V Pioneer is a few years old and implements only RV64GC, a draft version of the Vector extension and T-Head's own proprietary extensions where many instructions can do the same as officially ratified extensions but using different opcodes.

In Milk-V Pioneer is present a Sophon SG2042, why did you say it was a XuanTie T-Head 910/920 ?

 

[acadia11]

Interesting, but I probably sucked at explaining my train of thought here. If RISC was on an equal playing field (like, say, it had have licensed those instruction sets, or the instruction sets weren't needed); if RISC was able to advance at the same degree as Intel and AMD, I wonder where they'd be now

No worries, all here to discuss. RiSC is and has always been as advanced as CISC processors … maybe you were just thinking of only this specific use case? note, AmD and Intel have both made RISC processors as well. X86 is dominate in the desktop space, which has changed recently, But the short of it RISC computing has been around just as long and is just as advanced, ARM which is probably the most well known RISC implementation/company is nearly 40 years old. dEC alphas were the most advanced processors and fastest when pentiums were in their heyday, and actually contributed to creation of AMDs athlon. RISC isn’t inherently better or worse than CISC but it is better when transistor counts, cache sizes and power consumption matter this advantage except for transistor count is less important today. But there are plenty use cases where a complex instruction will definitely speed up processing and is better, which is why CISC processors exists to begin with. The bottom line RISC is advanced but it has a different strengths and weaknesses and isn’t necessarily worse or better, but certainly not less advanced ornot as well developed.

 

[NinoPino]

No worries, all here to discuss. RiSC is and has always been as advanced as CISC processors … maybe you were just thinking of only this specific use case? note, AmD and Intel have both made RISC processors as well. X86 is dominate in the desktop space, which has changed recently, But the short of it RISC computing has been around just as long and is just as advanced, ARM which is probably the most well known RISC implementation/company is nearly 40 years old. dEC alphas were the most advanced processors and fastest when pentiums were in their heyday, and actually contributed to creation of AMDs athlon. RISC isn’t inherently better or worse than CISC but it is better when transistor counts, cache sizes and power consumption matter this advantage except for transistor count is less important today. But there are plenty use cases where a complex instruction will definitely speed up processing and is better, which is why CISC processors exists to begin with. The bottom line RISC is advanced but it has a different strengths and weaknesses and isn’t necessarily worse or better, but certainly not less advanced ornot as well developed.

For the most part I agree but the success of CISC is only due to the IBM-Intel monopoly before and to the Microsoft-Intel monopoly after. Absolutely not for an advantage of CISC versus RISC in any single usecase. RISC from the '80 till now demonstrated his technical superiority.

 

[The Historical Fidelity]

No worries, all here to discuss. RiSC is and has always been as advanced as CISC processors … maybe you were just thinking of only this specific use case? note, AmD and Intel have both made RISC processors as well. X86 is dominate in the desktop space, which has changed recently, But the short of it RISC computing has been around just as long and is just as advanced, ARM which is probably the most well known RISC implementation/company is nearly 40 years old. dEC alphas were the most advanced processors and fastest when pentiums were in their heyday, and actually contributed to creation of AMDs athlon. RISC isn’t inherently better or worse than CISC but it is better when transistor counts, cache sizes and power consumption matter this advantage except for transistor count is less important today. But there are plenty use cases where a complex instruction will definitely speed up processing and is better, which is why CISC processors exists to begin with. The bottom line RISC is advanced but it has a different strengths and weaknesses and isn’t necessarily worse or better, but certainly not less advanced ornot as well developed.

The Achilles heel of RISC processors is the code compiler used to compile software for it. CISC made sense back in the day when compilers were primitive. Nowadays, advanced RIS compilers can layout simple instructions efficiently to create de facto complex instructions in software. CISC is still powerful today, but (to use a novel writing analogy) there will come a time when it just doesn’t make sense to keep creating new more complex words that require translation to describe things when all you have to do as a writer is take basic English and arrange it in the proper order.
Sure CISC makes it easier to compile software, but the thing is that compiling happens once, but the extra energy used, every time the software is run, to power all the additional silicon real estate needed to take CISC instructions and break them down into a series of basic instructions (interestingly, modern Intel and AMD cores are essentially a form of RISC that feature CISC translation decoders) seems less and less ideal now that machine learning can optimize compilers for maximum efficiency allowing processors to be fed basic instructions from the start.
It just makes sense that software compilers will essentially replace hardware decoders.

 

[NinoPino]

The Achilles heel of RISC processors is the code compiler used to compile software for it. CISC made sense back in the day when compilers were primitive. Nowadays, advanced RIS compilers can layout simple instructions efficiently to create de facto complex instructions in software. CISC is still powerful today, but (to use a novel writing analogy) there will come a time when it just doesn’t make sense to keep creating new more complex words that require translation to describe things when all you have to do as a writer is take basic English and arrange it in the proper order.
Sure CISC makes it easier to compile software, but the thing is that compiling happens once, but the extra energy used, every time the software is run, to power all the additional silicon real estate needed to take CISC instructions and break them down into a series of basic instructions (interestingly, modern Intel and AMD cores are essentially a form of RISC that feature CISC translation decoders) seems less and less ideal now that machine learning can optimize compilers for maximum efficiency allowing processors to be fed basic instructions from the start.
It just makes sense that software compilers will essentially replace hardware decoders.

Here I disagree at all, if we want to produce efficient code, a compiler for a simpler instruction set with 40/50 well designed instructions and a lot of general purpose registers will be always easier to build than a compiler for an instruction set with hundreds of instructions all different in syntax and with a little number of specialised registers.
If you want to find a typical disadvantage of RISC vs CISC, it is typically the code density, not many other.

 

[acadia11]

For the most part I agree but the success of CISC is only due to the IBM-Intel monopoly before and to the Microsoft-Intel monopoly after. Absolutely not for an advantage of CISC versus RISC in any single usecase. RISC from the '80 till now demonstrated his technical superiority.

I’ll give you a use case

The Achilles heel of RISC processors is the code compiler used to compile software for it. CISC made sense back in the day when compilers were primitive. Nowadays, advanced RIS compilers can layout simple instructions efficiently to create de facto complex instructions in software. CISC is still powerful today, but (to use a novel writing analogy) there will come a time when it just doesn’t make sense to keep creating new more complex words that require translation to describe things when all you have to do as a writer is take basic English and arrange it in the proper order.
Sure CISC makes it easier to compile software, but the thing is that compiling happens once, but the extra energy used, every time the software is run, to power all the additional silicon real estate needed to take CISC instructions and break them down into a series of basic instructions (interestingly, modern Intel and AMD cores are essentially a form of RISC that feature CISC translation decoders) seems less and less ideal now that machine learning can optimize compilers for maximum efficiency allowing processors to be fed basic instructions from the start.
It just makes sense that software compilers will essentially replace hardware decoders.

This would be true if there was no place for hardware acceleration on design which is essentially what creating CISC operations is about. Software compilers are more advanced today , but you are simply shifting the solution to software layer of how to construct an optimal algorithm to instruct a computer which will lead to larger programs. At the end of the day with the advent of advanced techniques for cpu design and AI application in hardware/processor design adoption of both CISC and RISC methodologies will be the norm and designing complex processors can be addressed. Today’s x86 processors aren’t purely CiSC designs in any case. And consider RISC reliance on larger cache and memory requirements will itself start impacting power requirements my opinion I still don’t believe it’s an either or situation but use case and likely amalgamated solution in the future.

 

[The Historical Fidelity]

Here I disagree at all, if we want to produce efficient code, a compiler for a simpler instruction set with 40/50 well designed instructions and a lot of general purpose registers will be always easier to build than a compiler for an instruction set with hundreds of instructions all different in syntax and with a little number of specialised registers.
If you want to find a typical disadvantage of RISC vs CISC, it is typically the code density, not many other.

I appreciate your rebuttal and in theory I believe your opinion is correct about code density, however, in practice, it seems the quality of compilers does have a major role in performance optimization of RISC processors and memory access needs.

Also, I believe you are mistaking RISC for MISC (Minimum Instruction Set Computer) Remember, RISC does not = low number of instructions in set, many RISC processors have instruction set sizes = to CISC, the difference is that RISC instructions can all be enacted in 1 single clock cycle.

“ Advantages of RISC processors: Reducing the complexity of the instruction set performed by the hardware paves the way for providing flexible intelligence by using software rather than hardware. As a result, a RISC architecture design requires greater complexity on the compiler.”

“ The RISC architecture contains a set of instructions. This allows high-level language compilers to create more efficient code.”

“Disadvantages of RISC processors: The performance of the RISC processor can depend on the compiler. Because the knowledge of the compiler has a crucial role while translating the CISC code to RISC code, it requires so much complexity in the compiler.”

-https://www.baeldung.com/cs/risc-vs-cisc

“ Compiler technology has also become more sophisticated, so that the RISC use of RAM and emphasis on software has become ideal.”

RISC vs. CISC

“….they showed that a compiler tuned to use registers wherever possible would run code about three times as fast as traditional designs.”

J. Cocke and V. Markstein, "The evolution of RISC technology at IBM," in IBM Journal of Research and Development, vol. 34, no. 1, pp. 4-11, Jan. 1990, doi: 10.1147/rd.341.0004.

“ Patterson's early work pointed out an important problem with the traditional "more is better" approach; even those instructions that were critical to overall performance were being delayed by their trip through the microcode. If the microcode was removed, the programs would run faster. And since the microcode ultimately took a complex instruction and broke it into steps, there was no reason the compiler couldn't do this instead. These studies suggested that, even with no other changes, one could make a chip with 1⁄3 fewer transistors that would run faster.”

https://web.archive.org/web/2022061...son.mx/~havillam/ca/CS323/0708.cs-323005.html

“Like any architectural approach, both RISC and CISC have their strengths and weaknesses. Understanding these tradeoffs is critical to designing efficient and optimized computer systems.

RISC architectures are characterized by performance, energy efficiency and compiler optimization. By emphasizing simplicity and consistency, RISC architectures can achieve shorter cycle times and lower power consumption compared to CISC architectures. Additionally, the simplified instruction set and execution model facilitate compiler optimization and enable more efficient program execution.

However, one disadvantage of RISC architectures is that they require access to memory for almost every operation. This can increase the number of instructions required to perform certain tasks, resulting in larger code sizes and higher memory bandwidth requirements.

CISC architectures, on the other hand, offer more flexibility and convenience as they provide complex commands that can perform multiple operations in a single command. This can be beneficial in certain scenarios where efficiency is critical, such as: B. in multimedia applications or complex mathematical calculations. However, the higher complexity of the instruction set can lead to longer cycle times and higher power consumption.

Additionally, the larger code size of CISC instructions can pose a challenge for compiler optimization, making it more difficult to achieve the same level of efficiency as with RISC architectures.“

Understanding RISC and its impact on computer architectures Test 2024 [December] • Techwatch.de

Discover the fascinating world of RISC and its profound influence on computer architectures.

techwatch.de

“Some aspects attributed to the first RISC-labeled designs around 1975 include the observations that the memory-restricted compilers of the time were often unable to take advantage of features intended to facilitate manual assembly coding, and that complex addressing modes take many cycles to perform due to the required additional memory accesses. It was argued that such functions would be better performed by sequences of simpler instructions if this could yield implementations small enough to leave room for many registers, reducing the number of slow memory accesses. In these simple designs, most instructions are of uniform length and similar structure, arithmetic operations are restricted to CPU registers and only separate load and store instructions access memory. These properties enable a better balancing of pipeline stages than before, making RISC pipelines significantly more efficient and allowing higher clock frequencies.

The clock rate of a CPU is limited by the time it takes to execute the slowest sub-operation of any instruction; decreasing that cycle-time often accelerates the execution of other instructions. The focus on "reduced instructions" led to the resulting machine being called a "reduced instruction set computer" (RISC). The goal was to make instructions so simple that they could easily be pipelined, in order to achieve a single clock throughput at high frequencies. This contrasted with CISC designs whose "crucial arithmetic operations and register transfers" were considered difficult to pipeline.
Later, it was noted that one of the most significant characteristics of RISC processors was that external memory was only accessible by a load or store instruction. All other instructions were limited to internal registers. This simplified many aspects of processor design: allowing instructions to be fixed-length, simplifying pipelines, and isolating the logic for dealing with the delay in completing a memory access (cache miss, etc.) to only two instructions. This led to RISC designs being referred to as load–store architectures.”

https://www.drdobbs.com/programmers-bookshelf/184408418

https://archive.org/details/internationalcom0000yvon/page/83/mode/1up

https://archive.org/details/highperformancec00dowd

https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf

 

[The Historical Fidelity]

I’ll give you a use case

This would be true if there was no place for hardware acceleration on design which is essentially what creating CISC operations is about. Software compilers are more advanced today , but you are simply shifting the solution to software layer of how to construct an optimal algorithm to instruct a computer which will lead to larger programs. At the end of the day with the advent of advanced techniques for cpu design and AI application in hardware/processor design adoption of both CISC and RISC methodologies will be the norm and designing complex processors can be addressed. Today’s x86 processors aren’t purely CiSC designs in any case. And consider RISC reliance on larger cache and memory requirements will itself start impacting power requirements my opinion I still don’t believe it’s an either or situation but use case and likely amalgamated solution in the future.

I already stated that modern AMD and Intel cores are RISC-like with attached complex instructions decoders (a hardware RISC compiler of sorts). The problem with your argument about “memory requirements impacting power” usage is that memory sips power compared to processor cores and memory power usage has always scaled down better than processor power usage. So by RISC simplifying and eliminating transistor bloat by offsetting their job to the compiler, it will always yield better power efficiency in spite of increased memory access requirements. And modern power gated caches can be quite efficient compared to the logic portion of a core. For example, Niagara-2’s cache power consumption during heavy workloads is ~24% of total core power consumption. Since the logic portion of the power consumption is more energy efficient in the first place due to RISC, the total core power consumption still beats CISC designs by a good margin.

And not sure how “ hardware acceleration on design which is essentially what creating CISC operations is about” has anything to do with eachother. It is not hardware acceleration when the CISC processor has to take the complex instruction, break it down into micro-ops, then compute it in RISC fashion (modern X86 is RISC cores with Complex instruction hardware decoders). If you are relating AVX and other such things as “hardware acceleration” then I guess but no one really considers that an accelerator. RISC processors also have wide bit length floating point pipelines as well.

 

[NinoPino]

Oh man, what a post! 😅

I appreciate your rebuttal and in theory I believe your opinion is correct about code density, however, in practice, it seems the quality of compilers does have a major role in performance optimization of RISC processors and memory access needs.

Here it depends on what you consider "compiler side optimization" and what you intend for "compiler complexity".
For me, the implementation of a missing assembler instruction do not make a compiler more complex for some reasons.
- the really necessary and missing instructions that need a complex implementation are very few
- the missing instructions that need a reimplementation are typically very simple. Take multiplication and division like examples.
- once implemented, the compiler insert a simple jump to subroutine or infine expansion and this do not cause more complexity in the optimization phase that is the really complex part of the compiler
- in the total complexity of a compiler, considering all the steps needed to go from the source to the executable, the implementation of few instructions do not impact significantly and is more than compensated from the benefits given to the compiler by the increased registers numbers the more coherent instructions, the alignment, the uniform instructions latencies.

Also, I believe you are mistaking RISC for MISC (Minimum Instruction Set Computer)

Not at all. I take as example the first commercially available ARM, the ARM2 of 1987. It is comparable for period, target and performance to the Intel 80386.
In the ARM you only had 6 distinct instruction formats and a total of 21-27 different instructions (the variability depends from what is interpreted as a parameter or a different instruction).
I let to you to compare the 30 distinct instructions on the ARM2 versus those of 80386... (Source : Archimedes Assembly Language, Mike Ginns, Dabs Press)

Remember, RISC does not = low number of instructions in set, many RISC processors

Yes it is, the achronim means this, "Reduced Istruction Set".
Reduced set, in particolar at the beginning, was needed to avoid wasting transistors on seldom used instructions simplifying the design. This was done with a small number of simple but effective instructions.

have instruction set sizes = to CISC, the

With the years RISCs increased the number of instructions but also CISC have done. But RISCs will always have advantage of a better structured and simpler approach of the istructions.

difference is that RISC instructions can all be enacted in 1 single clock cycle.

This is not true. For obvious reasons some instructions needed multiple clock cycles.
The 1 clock cycle rule is valid for the majority of the instructions but not for all as you wrote.

“ Advantages of RISC processors: Reducing the complexity of the instruction set performed by the hardware paves the way for providing flexible intelligence by using software rather than hardware. As a result, a RISC architecture design requires greater complexity on the compiler.”

As said before, for me is true the opposite because a RISC ISA is more easy to optimize for the compiler.

“ The RISC architecture contains a set of instructions. This allows high-level language compilers to create more efficient code.”

This is in contrast with what you said before about compiler complexity.

“Disadvantages of RISC processors: The performance of the RISC processor can depend on the compiler. Because the

As CISCs and any other CPU, but the streamlined ISA permit to obtain a less variant executable and to squeeze easily all the availables performance.

knowledge of the compiler has a crucial role while translating the CISC code to RISC code, it requires so much complexity in the compiler.”

Not "so much" but only an insignificant amount compared to all the advantages to the compiler itself.

-https://www.baeldung.com/cs/risc-vs-cisc

“ Compiler technology has also become more sophisticated, so that the RISC use of RAM and emphasis on software has become ideal.”

RISC vs. CISC

“….they showed that a compiler tuned to use registers wherever possible would run code about three times as fast as traditional designs.”

J. Cocke and V. Markstein, "The evolution of RISC technology at IBM," in IBM Journal of Research and Development, vol. 34, no. 1, pp. 4-11, Jan. 1990, doi: 10.1147/rd.341.0004.

“ Patterson's early work pointed out an important problem with the traditional "more is better" approach; even those instructions that were critical to overall performance were being delayed by their trip through the microcode. If the microcode was removed, the programs would run faster. And since the microcode ultimately took a complex instruction and broke it into steps, there was no reason the compiler couldn't do this instead.

The fact that "compiler could do it instead" do not imply that the compiler is more complex but only that it need to output more instructions than what could be needed in the CISC case.

These studies suggested that, even with no other changes, one could make a chip with 1⁄3 fewer transistors that would run faster.”

https://web.archive.org/web/2022061...son.mx/~havillam/ca/CS323/0708.cs-323005.html

“Like any architectural approach, both RISC and CISC have their strengths and weaknesses. Understanding these tradeoffs is critical to designing efficient and optimized computer systems.

RISC architectures are characterized by performance, energy efficiency and compiler optimization. By emphasizing simplicity and consistency, RISC architectures can achieve shorter cycle times and lower power consumption compared to CISC architectures. Additionally, the simplified instruction set and execution model facilitate compiler optimization and enable more efficient program execution.

As I said above about compiler complexity.

However, one disadvantage of RISC architectures is that they require access to memory for almost every operation.

Not true. Why ?

This can increase the number of instructions required to perform certain tasks, resulting in larger code sizes and higher memory bandwidth requirements.

Agree, the code density is typically a RISC's weakness.

CISC architectures, on the other hand, offer more flexibility and convenience as they provide complex commands that can perform multiple operations in a single command. This can be beneficial in certain scenarios where efficiency is critical, such as: B. in multimedia applications or complex mathematical calculations.

I would not restrict the advantage to multimedia but to all the complex tasks that can take advantage of instructions specifically designed for the task. Not many CISC CPUs have had native instructions designed to advantage multimedia tasks.
But this is not strictly the field of CISCs but rather of SIMD instructions that nowadays are omnipresent in CISCs and RISCs.

However, the higher complexity of the instruction set can lead to longer cycle times and higher power consumption.

Additionally, the larger code size of CISC instructions can pose a challenge for compiler optimization, making it more difficult to achieve the same level of efficiency as with RISC architectures.“

If with "code size" we means machine code instruction length I disagree because as said before the code density of CISC is typically higher.
If with "code size" we means the different size of the various instructions than of course I agree.

Understanding RISC and its impact on computer architectures Test 2024 [December] • Techwatch.de

Discover the fascinating world of RISC and its profound influence on computer architectures.

techwatch.de

“Some aspects attributed to the first RISC-labeled designs around 1975 include the observations that the memory-restricted compilers of the time were often unable to take advantage of features intended to facilitate manual assembly coding, and that complex addressing modes take many cycles to perform due to the required additional memory accesses.

Again another confirmation of the fact that compilers for CISC CPUs are more complex than that for RISC.

It was argued that such functions would be better performed by sequences of simpler instructions if this could yield implementations small enough to leave room for many registers, reducing the number of slow memory accesses. In these simple designs, most instructions are of uniform length and similar structure, arithmetic operations are restricted to CPU registers and only separate load and store instructions access memory. These properties enable a better balancing of pipeline stages than before, making RISC pipelines significantly more efficient and allowing higher clock frequencies.

The clock rate of a CPU is limited by the time it takes to execute the slowest sub-operation of any instruction; decreasing that cycle-time often accelerates the execution of other instructions. The focus on "reduced instructions" led to the resulting machine being called a "reduced instruction set computer" (RISC). The goal was to make instructions so simple that they could easily be pipelined, in order to achieve a single clock throughput at high frequencies. This contrasted with CISC designs whose "crucial arithmetic operations and register transfers" were considered difficult to pipeline.
Later, it was noted that one of the most significant characteristics of RISC processors was that external memory was only accessible by a load or store instruction. All other instructions were limited to internal registers. This simplified many aspects of processor design: allowing instructions to be fixed-length, simplifying pipelines, and isolating the logic for dealing with the delay in completing a memory access (cache miss, etc.) to only two instructions. This led to RISC designs being referred to as load–store architectures.”

Ofcourse here I agree.

https://www.drdobbs.com/programmers-bookshelf/184408418

https://archive.org/details/internationalcom0000yvon/page/83/mode/1up

https://archive.org/details/highperformancec00dowd

https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf

 

[The Historical Fidelity]

Oh man, what a post! 😅


Here it depends on what you consider "compiler side optimization" and what you intend for "compiler complexity".
For me, the implementation of a missing assembler instruction do not make a compiler more complex for some reasons.
- the really necessary and missing instructions that need a complex implementation are very few
- the missing instructions that need a reimplementation are typically very simple. Take multiplication and division like examples.
- once implemented, the compiler insert a simple jump to subroutine or infine expansion and this do not cause more complexity in the optimization phase that is the really complex part of the compiler
- in the total complexity of a compiler, considering all the steps needed to go from the source to the executable, the implementation of few instructions do not impact significantly and is more than compensated from the benefits given to the compiler by the increased registers numbers the more coherent instructions, the alignment, the uniform instructions latencies.


Not at all. I take as example the first commercially available ARM, the ARM2 of 1987. It is comparable for period, target and performance to the Intel 80386.
In the ARM you only had 6 distinct instruction formats and a total of 21-27 different instructions (the variability depends from what is interpreted as a parameter or a different instruction).
I let to you to compare the 30 distinct instructions on the ARM2 versus those of 80386... (Source : Archimedes Assembly Language, Mike Ginns, Dabs Press)

Yes it is, the achronim means this, "Reduced Istruction Set".
Reduced set, in particolar at the beginning, was needed to avoid wasting transistors on seldom used instructions simplifying the design. This was done with a small number of simple but effective instructions.


With the years RISCs increased the number of instructions but also CISC have done. But RISCs will always have advantage of a better structured and simpler approach of the istructions.


This is not true. For obvious reasons some instructions needed multiple clock cycles.
The 1 clock cycle rule is valid for the majority of the instructions but not for all as you wrote.


As said before, for me is true the opposite because a RISC ISA is more easy to optimize for the compiler.


This is in contrast with what you said before about compiler complexity.


As CISCs and any other CPU, but the streamlined ISA permit to obtain a less variant executable and to squeeze easily all the availables performance.


Not "so much" but only an insignificant amount compared to all the advantages to the compiler itself.


The fact that "compiler could do it instead" do not imply that the compiler is more complex but only that it need to output more instructions than what could be needed in the CISC case.


As I said above about compiler complexity.


Not true. Why ?


Agree, the code density is typically a RISC's weakness.


I would not restrict the advantage to multimedia but to all the complex tasks that can take advantage of instructions specifically designed for the task. Not many CISC CPUs have had native instructions designed to advantage multimedia tasks.
But this is not strictly the field of CISCs but rather of SIMD instructions that nowadays are omnipresent in CISCs and RISCs.


If with "code size" we means machine code instruction length I disagree because as said before the code density of CISC is typically higher.
If with "code size" we means the different size of the various instructions than of course I agree.


Again another confirmation of the fact that compilers for CISC CPUs are more complex than that for RISC.



Ofcourse here I agree.

All due respect but forgive me if i am a bit skeptical of your opinions in the face of peer-reviewed journal articles, institutional publications, etc.. You may actually be correct, but I have no way of judging your statements unless perhaps you can find a publication that supports your assertions? Again not trying to be disrespectful, just fascinated with this conversation and eager to learn more. And thank you for your time!

 

[acadia11]

I already stated that modern AMD and Intel cores are RISC-like with attached complex instructions decoders (a hardware RISC compiler of sorts). The problem with your argument about “memory requirements impacting power” usage is that memory sips power compared to processor cores and memory power usage has always scaled down better than processor power usage. So by RISC simplifying and eliminating transistor bloat by offsetWting their job to the compiler, it will always yield better power efficiency in spite of increased memory access requirements. And modern power gated caches can be quite efficient compared to the logic portion of a core. For example, Niagara-2’s cache power consumption during heavy workloads is ~24% of total core power consumption. Since the logic portion of the power consumption is more energy efficient in the first place due to RISC, the total core power consumption still beats CISC designs by a good margin.

And not sure how “ hardware acceleration on design which is essentially what creating CISC operations is about” has anything to do with eachother. It is not hardware acceleration when the CISC processor has to take the complex instruction, break it down into micro-ops, then compute it in RISC fashion (modern X86 is RISC cores with Complex instruction hardware decoders). If you are relating AVX and other such things as “hardware acceleration” then I guess but no one really considers that an accelerator. RISC processors also have wide bit length floating point pipelines as well.

Ok, lot to unpack on this one. When this debate started CISC vs RISC decades ago is very different from today. With many new features in design on both CISC and RISC front, which marries both concepts and in fact brings new concepts all together into the fold that simply didn't exists then. RISC designs are becoming just as complex today because of the newer(ish) 90's , 2000's vs the 70's and 80's paradigms in CPU architecture including Out of Order execution, branch prediction / speculative execution, etc ... that didn't exists when processors were in their infancy. And that there is convergence of concepts across the board in RISC and CISC that has created an arena where it's not either or or but best fit for your use case.

As to memory and cache , you are correct modern power gated caches do reduce consumption and heat, but it's more to the point that as RISC like processors become more important in the server / data center / workstation space memory requirements will change and this adds it's own variable, die size, transistor counts etc ... . And ultimately, strictly CISC processors and strictly RISC processors or ones that adhere to academic ethos of either is farther away from the reality of processor design today and towards the future.

 

[epobirs]

The R in ARM stands for “reduced instruction set” which is a generic term for any microarchitecture that emphasizes barebones instructions (compared to x86 which is a “complex instruction set architecture”) that requires more advanced compilers to layout said instructions in a way that complex instructions are created in software. Reduced instruction set CPUs are greatly affected by the quality of the compiler used for the code being run.
By reducing the instruction set, the micro-architectures become less intricate because they can free up transistor space that used to be occupied by complex instruction decoders, translators, and hardware that enables legacy instruction support (dating back to the 1970’s for x86 so has a quite bloated instruction set where some instructions are rarely used nowadays) to be reallocated to improve IPC and power efficiency. This is the only reason why Apple’s M-series chips are faster clock-for-clock if not held back by inferior compiling.

Did you think you were telling me anything I didn't already know in 1986 when the first ARM product, the Archimedes desktop system, came out?

 

[The Historical Fidelity]

Did you think you were telling me anything I didn't already know in 1986 when the first ARM product, the Archimedes desktop system, came out?

Okay, you passed the test Hahaha