RISC-V Processor Achieves 5 GHz Frequency at Just 1 Watt of Power

[Vayra86]

But.. Does it run Crysis?

It does but you can't see it, no display.

They also tried running the Remastered version but it bluescreened.

 

[ratirt]

"Based on RISC" is kind of a misnomer.

ARM is a family of RISC processors. ARM stands for Advanced RISC Machine. So based on Risc as an architecture or Risc philosophy does it really matter if one terminology is better than the other?

 

[Vya Domus]

Smartphone SoC runs a lot more stuff under load.

But for a single core I bet they don't use much more than 1 Watt as well, especially once the throttling kicks in.

 

[silentbogo]

ARM and RISC-V are both RISC and use same core ISA but each one can extend it. At least that's what I thought it was.

RISC is a general term, like a "automobile" or "vegetable". It only means that CPU uses reduced instruction set, which nowadays has very little meaning.

The ISA itself matters little, the reason everyone got exited about RISC-V is that it's open source. You can more or less design identical processors using ARM or RISC-V.

It matters a lot. One of the major reasons RISC-V is gaining traction, is because it's not overburdened by legacy feature support, which makes it simple and more efficient than ARM or MIPS. Many large companies started transition to this arch a couple of years ago, mostly for low-power or highly-specialized stuff. You are using a RISC-V CPU right now at this very moment without even knowing about it

 

[Vya Domus]

One of the major reasons RISC-V is gaining traction, is because it's not overburdened by legacy feature support, which makes it simple and more efficient than ARM or MIPS.

It also makes off limits for a lot of segments. Nearly all of the software is written for x86 and ARM and emulation doesn't make people happy.

Many large companies started transition to this arch a couple of years ago, mostly for low-power or highly-specialized stuff. You are using a RISC-V CPU right now at this very moment without even knowing about it

For relatively insignificant purposes, of course companies would rather get some free open design for something like a controller rather than get a core from ARM. But outside of that, I really don't see it gaining that much traction.

 

[Valantar]

Aren't WD's in-house SSD controllers the most high-profile consumer RISC-V design out there? Or is there something else that I've missed?

 

[pjl321]

I'm waiting for RISC-VI

 

[bug]

I'm waiting for RISC-VI

RISC-X or bust

 

[silentbogo]

For relatively insignificant purposes, of course companies would rather get some free open design for something like a controller rather than get a core from ARM. But outside of that, I really don't see it gaining that much traction.

Depends on what you mean by "insignificant" purpose. Scheduler in your GTX1080 is quite significant. SSD controllers are quite significant. Networking processors are even more significant than all of our Zens and Lakes combined.

It also makes off limits for a lot of segments. Nearly all of the software is written for x86 and ARM and emulation doesn't make people happy.

Why emulation? What does it even have to do with this?
Embedded software is a lot simpler to port natively, and you underestimate how much effort people and companies are willing to invest into this arch.
There are already functional ports of Linux, RTOS and others. Freebsd will bump RISC-V to Tier 2 on their next release, which will put it on the same priority list with AARCH64 and MIPS64.
GCC supports 32 and 64-bit RISC-V, so I don't see any software problem here.

 

[Vya Domus]

Why emulation? What does it even have to do with this?
Embedded software is a lot simpler to port natively, and you underestimate how much effort people and companies are willing to invest into this arch.
There are already functional ports of Linux, RTOS and others. Freebsd will bump RISC-V to Tier 2 on their next release, which will put it on the same priority list with AARCH64 and MIPS64.
GCC supports 32 and 64-bit RISC-V, so I don't see any software problem here.

No matter how simple it is to port it's still a problem to companies and they would much rather continue using ARM.

Depends on what you mean by "insignificant" purpose. Scheduler in your GTX1080 is quite significant. SSD controllers are quite significant. Networking processors are even more significant than all of our Zens and Lakes combined.

Like I said, it's mostly controllers. And in the case of Nvidia it isn't actually used as a scheduler, as in the logic that distributes instructions to SMs, it's used to intercept the commands streams from the host and then pass it on to the scheduler, it wouldn't be fast enough for that.

 

[DeathtoGnomes]

Aren't WD's in-house SSD controllers the most high-profile consumer RISC-V design out there? Or is there something else that I've missed?

Yes, for the most part, but not all that distinguished from other controllers.

 

[Aquinus]

ARM is a family of RISC processors. ARM stands for Advanced RISC Machine. So based on Risc as an architecture or Risc philosophy does it really matter if one terminology is better than the other?

RISC and CISC are types of CPUs, you can have two RISC or two CISC CPUs that are very different. Traditionally the main difference between them has to do with accessing memory within the context of an instruction. For example, an x86 instruction might do an memory load and store operation along with some logic whereas most RISC implementations demand an explicit load and store op before doing calculations, however that's really where the similarities end. RISC-V and ARM are two very different instruction sets with different designs and assumptions baked in.

So yes, it does matter.

 

[hurakura]

enough of this bs, where are the quantum computers

 

[Valantar]

enough of this bs, where are the quantum computers

In the distant future.

 

[Vya Domus]

In the distant future.

And on top of that they're only useful for a bunch of types of problems.

 

[bonehead123]

I'm waiting for RISC-VI

We, I'm waitin for the xxx, super, ti, OC, or ++++ versions to come into being, then maybe it will be viable for certain use cases, hahahaha

 

[dragontamer5788]

ARM is a family of RISC processors. ARM stands for Advanced RISC Machine. So based on Risc as an architecture or Risc philosophy does it really matter if one terminology is better than the other?

ARM used to be a family of RISC processors.

Then they added SIMD, AES instructions, Javascript instructions, Java instructions (Jazelle), variable-length instructions (Thumb, and Thumb2), then decided to remove the variable-length instructions and make things 64-bits. The whole RISC philosophy started back in the 80s when CPUs started to get complicated multicycle microcode instructions... you know, like "divide" or "modulo". RISC was like "No point making a divide instruction: just have compilers emit the sequence of microcode in actual code". And then ARM got a divide instruction.

---------

RISC is basically a CPU-architecture version of "OOP Programming" or "Agile Development". It kinda sorta means something in theory, but in practice, it really doesn't (because as soon as real designs start to come out, you violate all sorts of principles. Because you can't make a theoretically perfect design to any static philosophy of engineering).

 

[bug]

ARM used to be a family of RISC processors.

Then they added SIMD, AES instructions, Javascript instructions, Java instructions (Jazelle), variable-length instructions (Thumb, and Thumb2), then decided to remove the variable-length instructions and make things 64-bits. The whole RISC philosophy started back in the 80s when CPUs started to get complicated multicycle microcode instructions... you know, like "divide" or "modulo". RISC was like "No point making a divide instruction: just have compilers emit the sequence of microcode in actual code". And then ARM got a divide instruction.

Spot on.

RISC is basically a CPU-architecture version of "OOP Programming" or "Agile Development". It kinda sorta means something in theory, but in practice, it really doesn't (because as soon as real designs start to come out, you violate all sorts of principles. Because you can't make a theoretically perfect design to any static philosophy of engineering).

Not so spot on. Like OOP or agile development, RISC is also a concept. Implementations tend to not stick to the concepts 100%
In the 80s, the distinction was pretty clear cut. It got blurred over time, but ISAs that trace their roots that far have kept the names.

 

[dragontamer5788]

Spot on.


Not so spot on. Like OOP or agile development, RISC is also a concept. Implementations tend to not stick to the concepts 100%
In the 80s, the distinction was pretty clear cut. It got blurred over time, but ISAs that trace their roots that far have kept the names.

The hilarious part of RISC-V is that "you can add your own instructions to the core". That's the entire freaking point of RISC-V: tons and tons of instruction sets being added at anybody's leisure, because its an open-source design. There's not one SIMD implementation, there's 3 or 4 SIMD implementations with competing goals.

The concept of a "Reduced Instruction Set Computer" (RISC) having an infinite number of instruction sets being added by everybody is... just lulz. Its a good idea from an "open-source" standpoint... but it runs entirely counter to the original RISC concept.

 

[Vya Domus]

ARM used to be a family of RISC processors.

Then they added SIMD, AES instructions, Javascript instructions, Java instructions (Jazelle), variable-length instructions (Thumb, and Thumb2), then decided to remove the variable-length instructions and make things 64-bits. The whole RISC philosophy started back in the 80s when CPUs started to get complicated multicycle microcode instructions... you know, like "divide" or "modulo". RISC was like "No point making a divide instruction: just have compilers emit the sequence of microcode in actual code". And then ARM got a divide instruction.

---------

RISC is basically a CPU-architecture version of "OOP Programming" or "Agile Development". It kinda sorta means something in theory, but in practice, it really doesn't (because as soon as real designs start to come out, you violate all sorts of principles. Because you can't make a theoretically perfect design to any static philosophy of engineering).

And that's why ISAs are actually mostly irrelevant, including RISC-V and the idea of having a RISC based ISA in general. Inside every modern CPU you essentially have an extra compiler that turns instructions in micro-ops and optimizes their execution.

RISC can only be a thing truly if you want to make a processor for micro controllers or something of the sort. Outside of that it's a waste of time.

 

[theeldest]

Risc V need a SOC like Raspberry pi ... or a desktop something cool and niech never happen though

They're coming. SiFive has a couple boards. The first is a fair bit bigger than a raspberry Pi (ITX, 16x PCIe slot, M.2 NVMe slot, 8GB memory). The other board they do is an Arduino competitor.

SiFive Boards - The best way to Develop RISC-V Software.

One-stop download for documentation, software development kits, toolchains, utilities, and software ecosystem solutions for each SiFive RISC-V development board.

www.sifive.com

I think we'll see some Pi form factor SBCs in the next couple years.

 

[jeremyshaw]

Aren't WD's in-house SSD controllers the most high-profile consumer RISC-V design out there? Or is there something else that I've missed?

Nvidia. Almost all of their current products use RISC-V. They are also one of the founding members of RISC-V group.

 

[bug]

The hilarious part of RISC-V is that "you can add your own instructions to the core". That's the entire freaking point of RISC-V: tons and tons of instruction sets being added at anybody's leisure, because its an open-source design. There's not one SIMD implementation, there's 3 or 4 SIMD implementations with competing goals.

The concept of a "Reduced Instruction Set Computer" (RISC) having an infinite number of instruction sets being added by everybody is... just lulz. Its a good idea from an "open-source" standpoint... but it runs entirely counter to the original RISC concept.

It's not like ARM doesn't come with its own share of extensions, but yeah...

And that's why ISAs are actually mostly irrelevant, including RISC-V and the idea of having a RISC based ISA in general. Inside every modern CPU you essentially have an extra compiler that turns instructions in micro-ops and optimizes their execution.

RISC can only be a thing truly if you want to make a processor for micro controllers or something of the sort. Outside of that it's a waste of time.

ISAs are very relevant, if you're the one collecting royalties for them
Joking aside, they're useful as a target for compilers. Much like the LLVM IR or JVM's bytecode is a target for several languages that don't need to bother with what happens beyond the IR or bytecode. None of them is a must per se, but in practice a layered approach is much saner.

 

[silentbogo]

enough of this bs, where are the quantum computers

Hiding in the same warehouse as flying cars and sexy androids.

RISC can only be a thing truly if you want to make a processor for micro controllers or something of the sort. Outside of that it's a waste of time.

Tell that to Alibaba group. I think they'll agree to disagree.
If memory serves me right, just a few years ago people were talking same crap about ARM, and look where we are today: #1 in top500 is ARM-based, new macbooks are ARM-based, tons of HPC enterprise solutions are popping up everywhere, and smartphones are becoming faster than our laptops and desktops. Don't forget that this whole movement stared with RISC-V foundation, which is only 5 years old, and they are making strides a lot faster (in both performance and adoption rate) than ARM.

And that's why ISAs are actually mostly irrelevant, including RISC-V and the idea of having a RISC based ISA in general. Inside every modern CPU you essentially have an extra compiler that turns instructions in micro-ops and optimizes their execution.

Same is true for ARM - just a core arch with a bunch of extensions. Modular and customizable, only comes with a bunch of legacies, redundancies, and tons of garbage in ISA itself.
Having a simple ISA makes it much easier to write/port/debug/optimize software, which is a complete opposite of what you think is happening with its ecosystem right now.
Linux kernel port went upstream almost 2 years ago, and I've already mentioned where we're at with BSD. That's the most important part, having a working kernel.
In regards to actual "software", just to give you a perspective, according to Debian wiki almost 95% of packages are buildable on RV64GC, which is comparable to PPC64. They are also working closely with Fedora team to solve issues faster and more efficiently. That's enough footing to easily port at least 8 out of top10 most popular Linux distributions, and regardless of your skepticism - it's happening as we speak.

. And in the case of Nvidia it isn't actually used as a scheduler, as in the logic that distributes instructions to SMs

Semantics... semantics.... It schedules warp schedulers

 

[dragontamer5788]

It's not like ARM doesn't come with its own share of extensions, but yeah...

I chose RISC-V as an example because:

1. While the "Advanced RISC Machine" has RISC in the acronym, the "RISC-V" CPU has the RISC acronym in its acronym. So it is "more obvious" that RISC-V is trying to be a RISC system.

2. ARM has plenty of extensions, but not quite as many as RISC-V, nor as convoluted. Western Digital probably has a whole bunch of special extensions in its RISC-V core for hard drive math and doesn't need to tell anybody about it. Most ARMs use the standard core and kind of add I/O peripherals (ie: Apple's Neural Engine, Qualcomm's DSP engine, microcontrollers and their ADC or GPIO pins, etc. etc.).

So you're right. Its just that I feel like "RISC-V" is a better example for #1 and #2. But ARM is also a perfectly fine example for how nonsensical "RISC vs CISC" debates have gotten recently.

If memory serves me right, just a few years ago people were talking same crap about ARM, and look where we are today: #1 in top500 is ARM-based, new macbooks are ARM-based, tons of HPC enterprise solutions are popping up everywhere, and smartphones are becoming faster than our laptops and desktops. Don't forget that this whole movement stared with RISC-V foundation, which is only 5 years old, and they are making strides a lot faster (in both performance and adoption rate) than ARM.

Ehhhh... just really M1 and A64Fx.

The thing about CPUs is that execution matters more than ISA or philosophy (like RISC). 5 years ago, there weren't any 8-wide ARM decoders with 300x register files with an 600-out-of-order window on 128kB L1 cache. Today there is.

Its not the 'ARM' or 'RISC' that matters. Its the freakishly huge cache, freakishly huge decoder, freakishly huge register file, and freakishly huge out-of-order window that matters. At some point the ISA has a degree of influence (ARM is probably easier to decode than x86). But the ISA itself isn't really the part of the chip that's "important" for performance. And mind you: despite Apple's M1 design clearly taking the single-core and IPC crown, I'm not entirely sure I agree with all the tradeoffs yet. Apple's M1 is literally twice as large as other cores: AMD Renoir fits 8x large cores + Vega iGPU on 10-billion transistors, while Apple M1 only has 4x large cores + iGPU + neural engine on 16-billion transistors.

Apple's strategy is "fewer cores with more IPC" to an incredible degree, the likes that we haven't seen before. Its a bold move. It might work, but I'm not 100% convinced its the best idea yet.

All of this RISC vs CISC stuff is 40 years out of date and ignores the bold design decisions that actually rocketed Apple to the #1 IPC / single core performance king. Bold because its contrary to the general story and general understanding of computers: any other CPU manufacturer would rather split such a wide core with hyper-threads at least, or run 2x cores instead of 1x double-sized core.