RISC, why did it never make it to larger Computing systems?

[CT_Biker]

More for RISC than for CISC. Performance hinges mostly on the quality of the code and how instructions are rearranged from CISC to RISC. Compilers are thus harder to implement and are more device specific as well as requiring a deeper understanding of the compiler. CISC pretty much doesn't matter as code will execute in the most efficient manner.

Would this not be something a compiler would need to handle and not the processor? For efficiencies sake, a well designed program, using a well designed complier should have similar compile time whether using RISC or CISC.

I did a simple test for this using an array look up and loop through an array containing 125 000 "items", both a RISC and CISC performed similarly when the programs were written in C, it should also be observed that both the RISC and CISC microprocessors ran the reverse look up almost 50 percent faster(though I suspect that this is mem cache related.)

I am going to assume that if the same exercise were done in Python, it would slower on both, but RISC may run a little more than marginally slower than a CISC microprocessor.

Another thing to note, is that I though I could use Processor Ticks to measure the speed of this, however the Intel processor I used and the Pi that I had on load seem to have completely different process clocks and counters.

Then again I am very new to embedded programming, so I am not even sure that I am looking at anything relevant. I have put off embedded until I am a better dev. Embedded programming was the key convincing factor that made me decide to go and study CS.

 

[sajunky]

Then again I am very new to embedded programming, so I am not even sure that I am looking at anything relevant. I have put off embedded until I am a better dev. Embedded programming was the key convincing factor that made me decide to go and study CS.

Take a time. When you start with embedded programming you can do everything in future.

 

[cguy]

More for RISC than for CISC. Performance hinges mostly on the quality of the code and how instructions are rearranged from CISC to RISC. Compilers are thus harder to implement and are more device specific as well as requiring a deeper understanding of the compiler. CISC pretty much doesn't matter as code will execute in the most efficient manner.

It's usually easy to compile for RISC, due to the orthogonal instruction set. Any CISC compiler is extremely device specific, having to handle instructions that only work with some registers, have much more variable latencies, and a lot more special purpose registers. Also, on the current multi-pipeline architectures, individual CISC instructions affect multiple and varying internal pipelines. In fact, apart from untranslated instruction size, all the RISC caveats apply to current CISC architectures, since they convert to RISC micro-ops internally.

The compiler does have to generate more code for RISC - funnily enough, this is what many textbooks consider making the compiler do "more work", when really, the optimizer is where the vast amount of the complexity is, and it's a harder problem for CISC architectures (e.g., should I use register BX, for this temp, when BX is one of the few indirect addressing registers, or CX, but CX is used for loop jump-and-decrement, this instruction uses pipelines P3 and P4, but this one uses just P3, etc.).

Maybe not but not what I was really referring to. RISC is most suited to where data can independently be executed in parallel. Where there's dependencies it doesn't function so well.

I think I see what you mean here. E.g., A load has to complete before it's data can be used in a subsequent instruction. CISC processors actually have the same limitation, it's just not visible at the instruction level, but will manifest as longer instruction latency (because internally, it becomes a load+OP) and multi-pipeline instructions. The CISC advantage is that the front-end doesn't have to fetch the two opcodes from memory/cache. On high performance RISC processors, micro-op fusion can be used to tie such dependencies together and treat them fast where possible (e.g., handle them in one front end cycle).

It requires larger on-die cache as well as memory bus as feeding the instructions require faster memory access.

That is a tiny amount of overhead these days (addresses are bigger, data is bigger, registers are bigger, speculative prefetching avoids latency delays). Intel even keeps a large micro-op cache itself to cache it's post-translated RISC op-codes, in addition to the instruction L1 cache.

 

[cguy]

Would this not be something a compiler would need to handle and not the processor? For efficiencies sake, a well designed program, using a well designed complier should have similar compile time whether using RISC or CISC.

I did a simple test for this using an array look up and loop through an array containing 125 000 "items", both a RISC and CISC performed similarly when the programs were written in C, it should also be observed that both the RISC and CISC microprocessors ran the reverse look up almost 50 percent faster(though I suspect that this is mem cache related.)

I am going to assume that if the same exercise were done in Python, it would slower on both, but RISC may run a little more than marginally slower than a CISC microprocessor.

Another thing to note, is that I though I could use Processor Ticks to measure the speed of this, however the Intel processor I used and the Pi that I had on load seem to have completely different process clocks and counters.

Then again I am very new to embedded programming, so I am not even sure that I am looking at anything relevant. I have put off embedded until I am a better dev. Embedded programming was the key convincing factor that made me decide to go and study CS.

An important piece that I think you're missing here, is that the performance characteristics of the processor implementation is vastly more important than whether or not it is CISC or RISC. Apart from edge cases, I would go as far to say that it doesn't really even matter. If the all of the clock speeds, cache sizes, cache/memory bandwidth, and uops/clock, and FLOPS are comparable, performance should be comparable. In practice, these will all typically be balanced differently, and relative performance will depend on the specifics of your program.

In general though, comparing parts that were built for different purposes (e.g., low power, small size, etc.), or at different price points (e.g., a $5 embedded chip vs a $500 desktop chip), makes little sense.

In order to do the performance comparisons you are doing fairly, you need to convert the ticks to a time unit such as nanoseconds. clock_gettime() does this reasonable efficiently using C/C++ on Linux. time.time() in Python. Neither of these are "free", so make sure that the workload you are doing amortizes their cost (I would recommend timing workloads over 100 micro secs).

 

[Swa]

Would this not be something a compiler would need to handle and not the processor? For efficiencies sake, a well designed program, using a well designed complier should have similar compile time whether using RISC or CISC.

I did a simple test for this using an array look up and loop through an array containing 125 000 "items", both a RISC and CISC performed similarly when the programs were written in C, it should also be observed that both the RISC and CISC microprocessors ran the reverse look up almost 50 percent faster(though I suspect that this is mem cache related.)

I am going to assume that if the same exercise were done in Python, it would slower on both, but RISC may run a little more than marginally slower than a CISC microprocessor.

Another thing to note, is that I though I could use Processor Ticks to measure the speed of this, however the Intel processor I used and the Pi that I had on load seem to have completely different process clocks and counters.

Then again I am very new to embedded programming, so I am not even sure that I am looking at anything relevant. I have put off embedded until I am a better dev. Embedded programming was the key convincing factor that made me decide to go and study CS.

And this is the issue. RISC shifts more of the optimisation onto the compiler making it harder to implement and removing some of the abstraction. CISC can be optimised as well but it's less of an issue with hardware optimisation. The issue is actually moot with most RISC based systems implementing CISC functionality and CISC based system reducing to RISC execution where appropriate. So it's no longer an issue of one vs the other any more.

It's usually easy to compile for RISC, due to the orthogonal instruction set. Any CISC compiler is extremely device specific, having to handle instructions that only work with some registers, have much more variable latencies, and a lot more special purpose registers. Also, on the current multi-pipeline architectures, individual CISC instructions affect multiple and varying internal pipelines. In fact, apart from untranslated instruction size, all the RISC caveats apply to current CISC architectures, since they convert to RISC micro-ops internally.

The compiler does have to generate more code for RISC - funnily enough, this is what many textbooks consider making the compiler do "more work", when really, the optimizer is where the vast amount of the complexity is, and it's a harder problem for CISC architectures (e.g., should I use register BX, for this temp, when BX is one of the few indirect addressing registers, or CX, but CX is used for loop jump-and-decrement, this instruction uses pipelines P3 and P4, but this one uses just P3, etc.).

That's actually easier to implement seeing most have a fixed purpose (not that you have to stick to that purpose). RISC requires a more in depth knowledge of the internal processor architecture in order to have code execute effectively. That's what most refer to with compilers being harder to implement as opposed to just the compiler having to do more work. Sure you can shift this onto the processor but then you actually make it more CISC like and reduce the benefits of the architecture.

I think I see what you mean here. E.g., A load has to complete before it's data can be used in a subsequent instruction. CISC processors actually have the same limitation, it's just not visible at the instruction level, but will manifest as longer instruction latency (because internally, it becomes a load+OP) and multi-pipeline instructions. The CISC advantage is that the front-end doesn't have to fetch the two opcodes from memory/cache. On high performance RISC processors, micro-op fusion can be used to tie such dependencies together and treat them fast where possible (e.g., handle them in one front end cycle).

Yes but also where instructions A and B are executed but instruction B depends on the output of instruction A. RISC works excellent where such dependencies don't exist and data variables can be worked on independently in parallel but where they do the knock on performance is often greater than with CISC which usually has better circuitry to perform instructions out of order and in stages.

That is a tiny amount of overhead these days (addresses are bigger, data is bigger, registers are bigger, speculative prefetching avoids latency delays). Intel even keeps a large micro-op cache itself to cache it's post-translated RISC op-codes, in addition to the instruction L1 cache.

If you want them to perform the same as CISC then yes. If you want the full advantage of RISC however you need instructions to execute a lot faster. This is a catch 22. If you have more cores you likely don't have the memory or the speed to feed them instructions. If you implement more and faster memory you don't have the space for more cores.