What kind of performance is expected from this compared to say the RPi 4B? Any noteworthy changes in performance characteristics (e.g better/worse I/O or something)?
I'm genuinely curious why that's desirable. Maybe I just misunderstand your comment and you want the RISC-V boards for validation i.e. make sure you can self-host the distro even if in general releases are cross-compiled on your (I assume AMD64) build fleet.
Even if you wanted to run a native RISC-V build process, running it in QEMU on a much more powerful AMD64 system will get you the same results in a fraction of the time. This gets much faster feedback in the CI system.
amd64 machines do have the advantage that you can get them with 32 or 64 cores and hundreds of GB of RAM -- at a price, especially in power consumption.
The three year old HiFive Unleashed uses around 5W to 6W at the wall when building flat out, considerably less than the maybe 25W a quad core i7 or Ryzen will use, with lower performance running qemu-system.
The new HiFive Unmatched probably has the same or lower power consumption, at 50% higher performance.
Running qemu on a Pi 4 would use about the same power as the RISC-V chip but be waaaaaaay slower.
I fully understand wanting native silicon to do development on and to work on some architecture specific branch. It's easy to just recompile your working copy locally. The original poster was talking about "build machines". I'm not seeing the utility as "build machines", especially if they have far less power than AMD64 machines.
In theory you can set up the build system to correctly know which things should be compiled native and which should be cross-compiled. Sometimes you even need native and cross-compiled versions of the same thing.
In practice, this is a capability that few people use and even if everything is set up correctly at some point most people contributing patches do not think about or test maintaining the ability to cross compile and it gets broken.
When you're building hundreds or thousands of packages for a distro such as Debian or Fedora this is a huge problem.
Building natively in a full system emulator or on real hardware is the only way, in practice.
Building under QEMU is obvious, however the native hardware is actually faster.
Do you expect a lot of things to break on RISCV?
https://fedoraproject.org/wiki/Architectures/RISC-V
Same for Debian, where the percentage of packages that build on RISC-V is second only to ppc64 out of the "minor" ISAs. https://buildd.debian.org/stats/graph-ports-week.png
https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW3...
Found that link from this SiFive page:
This board has a Dual-core U74 (RV64GC) 64-bit SoC @ 1.5 GHz with 2MB L2 cache. The U74 claims 2.5 DMIPS/MHz.
So, roughly 1/4 as fast as a RPIi 4B given the roughly half DMIPS/MHz and half the cores?
That, of course, is a really rough guess, ignoring lots of potential variables.
It's more MHz and a better uarch than the cores in a Pi 3, so should outperform even the newer Pi 3+ on tasks that don't use NEON and don't use more than 2 cores.
The hardware might be there to do some good audio processing, but how it integrates with the OS is something I'm not experienced with.