SiFive Details New Performance P650 RISC-V Core

[bob l'eponge]

There's https://github.com/vortexgpgpu/vortex for the GPU part (although, right now, it's mainly focused on OpenCL, a Vulkan compatible implementation is still far away).

As for the vector extension, you are wrong. There are vector extension in the RISC V instruction set. Unlike x86 and ARM8, the vector size is dynamic (there is no 128bits version, then 256 bits then 512 bits and so one). The CPU implementation actually dispatch the vectorized instruction as much as it's able to (so yes, there can be a 23 simultaneous operation per iterations in RISC V if the CPU has support for such number). This presents multiple advantages:
1. You don't need to rewrite your SIMD code when a new version of the CPU/architecture is out
2. The same code will always performs as fast as possible on RISC-V

The cons are less obvious:
1. You don't have as many vectorized instructions as a x86 CPU, so your pipeline might be struck by a non vectorized complex mask instruction for example.
2. You can't port your NEON, AVX, SSE2 assembly by just finding a 1:1 match in the right instruction. You have to rethink the algorithm à-la OpenMP way.

[kgardas]

Intel is stepping into the water and they plan to create horse creek dev. platform with p550 and with their other IP (dram/pcie). IIRC this is planned for '22: https://www.sifive.com/press/sifive-...ard-as-highest

https://www.anandtech.com/show/16780/intel-to-create-riscv-development-platform-with-sifive-p550-cores-on-7nm-in-2022

Mentioned process is Intel 7nm which IIRC was before Intel renamed them so it should be Intel 4 now. Correct me if I'm wrong here. Basically speaking Intel will test Intel 4 production with producing fastest sifive cores (which are really small) and make that advertisement for their foundry services and help risc-v movement and a little bit put sand to arm machine...

[Alexmitter]

It is not so impressive. It would be more impressive if it was mature.
At least from sifive, there is no performant board yet (remember all released boards have an in-order cpu, which means poor performance).
There are still lots of low hanging fruits to grab (OoO, prefetchers, branch predictors, etc.). When they run out of low hanging fruits, the progress in performance will be way slower.

tl;dr: It is easier to get faster when you are slow...

Keep in mind that those in order CPU cores already compete with OoO ARM Cores with all the fancy bells and whistles, and that at a significantly smaller footprint.
A main issue with the current FU chips is rather the low clock speed they have.

I can really not complain about the speed of my HiFive Unmatched, the only really painful thing about it is that so many things use Rust now but rust depends on the terrible joke called LLVM and that simply does not work right at all currently. So, no Firefox, not even smaller things with rust in it.

[Alexmitter]

That's not really accurate. The cores are actually marketed to SoC integrators, and they've set up a whole thing to help integrators get to fab. None of the SiFive cores previously mass produced were high performance, but they are in mass market products already. This core could easily fit into mass market products.

The cores are. Not the Chips SiFive makes themself, again SiFive is a design house making license core designs.
Of course could this core fit in a mass market product, no doubt. But it won't be SiFive who makes the Chip. Its gonna be Allwinner, or StarFive, or T-Head or any other actual SoC maker.

[PerformanceExpert]

Keep in mind that those in order CPU cores already compete with OoO ARM Cores with all the fancy bells and whistles, and that at a significantly smaller footprint.
A main issue with the current FU chips is rather the low clock speed they have.

The current in-order RISC-V cores don't even match a Cortex-A53. Show us the SPEC or Geekbench scores or stop spreading lies.

[PerformanceExpert]

There's https://github.com/vortexgpgpu/vortex for the GPU part (although, right now, it's mainly focused on OpenCL, a Vulkan compatible implementation is still far away).

As for the vector extension, you are wrong. There are vector extension in the RISC V instruction set. Unlike x86 and ARM8, the vector size is dynamic (there is no 128bits version, then 256 bits then 512 bits and so one). The CPU implementation actually dispatch the vectorized instruction as much as it's able to (so yes, there can be a 23 simultaneous operation per iterations in RISC V if the CPU has support for such number). This presents multiple advantages:

Yes, RISC-V finally has a vector extension. It's been discussed for many years, but it was only recently finished. So let's see how it performs and how it compares with SVE in actual hardware.

My point is no implementations with the vector extension exist yet (Xuantie 910 uses an earlier, incompatible version), and neither the P550 or P650 support it. That gets us to late 2023. So will any high-performance RISC-V core implement the vector extension before 2025?

1. You don't need to rewrite your SIMD code when a new version of the CPU/architecture is out
2. The same code will always performs as fast as possible on RISC-V

(1) is correct but (2) is an unsubstantiated claim. Code will never run as efficiently as possible on different microarchitectures. If you want it to run as fast as possible on a particular microarchitecture, you always need to tune the code.

The cons are less obvious:
1. You don't have as many vectorized instructions as a x86 CPU, so your pipeline might be struck by a non vectorized complex mask instruction for example.
2. You can't port your NEON, AVX, SSE2 assembly by just finding a 1:1 match in the right instruction. You have to rethink the algorithm à-la OpenMP way.

Plus 3 - it's not clear whether it is easy to implement in hardware, particularly on OoO core and give good performance.

[Anux]

Having roughly the same Performance as ARM is nice but what about power consumption? I would love to see a comparison on that front as soon as there is an actual SOC out there.

[microcode]

The cores are. Not the Chips SiFive makes themself, again SiFive is a design house making license core designs.
Of course could this core fit in a mass market product, no doubt. But it won't be SiFive who makes the Chip. Its gonna be Allwinner, or StarFive, or T-Head or any other actual SoC maker.

SiFive doesn't make chips, and you said “their cores are example implementations of the instruction set” which is what I was replying to. I'm glad you edited that out of your comment, but why challenge me on it now lol.

[hajj_3]

That would be very interesting, as that will give them scale to lower prices. Still, what GPU would be used in that case?

PowerVR works with risc-v chips.

So will any high-performance RISC-V core implement the vector extension before 2025?

Andes and other companies will be announcing cores on dec 6th at a risc-v summit. I assume there will be some cpu cores with vector support.

[coder]

Might be easier to do that with another SBC manufacturer. The Raspberry Pi Foundation for all of it's good aspects is essentially tied to Broadcom.

Not only that, just look at how long it's taking them to transition to AArch64!!

They have committed to something like a 10-year service life for each model they sell. So, I'm sure they don't want to add other ISAs to their support burden, if they can possibly avoid it.