5 ms·

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 someth

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)?

rwmj 6y ago
Highly unlikely to be very competitive. At this stage it's about getting RISC-V hardware into developers' hands, and previous boards either cost $1000 or were limited in ways where they could not run Linux well. (I am one of the Fedora/RISC-V maintainers.)
- deepGem 6y ago
  Just saw this SiFive board HiFive is retailing for $679, can you please comment if this is any good for toying around ? Specs look more than decent - almost desktop class computing. https://www.crowdsupply.com/sifive/hifive-unmatched https://www.crowdsupply.com/sifive/hifive-unmatched
  - rwmj 6y ago
    I have a couple on order, and I've talked to one of the developers. It looks nice - PCIe, NVRAM SSDs, mini ITX format, 16GB RAM, more cores, etc - but not in the same price point or market segment as an SBC. We will likely buy a pile of them to do Fedora builds.
    - giantrobot 6y ago
      Why would you want use these as build machines? It seems more efficient to just cross-compile on your fastest build machines. You get much faster CI feedback that way. Obviously you want to validate RISC-V code on native devices but using them as builders seems wasteful. 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.
      - FullyFunctional 6y ago
        I'm sure the Fedora builds aren't designed for cross compilation (which is far from trivial for most packages not designed for it). Also, man-power is the most precious resource so it would be a waste to spend time trying to cross-compile what could be built natively.
        giantrobot 6y ago
        As long as you've got the target toolchain on the host, the code has no idea it's being cross compiled. If you've got the tooling set up it's a lot of setting of envars. It's not trivial but it's also not super difficult. A compiler running native on an architecture doesn't produce any different output than the same compiler doing a cross compilation. 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.
        brucehoult 6y ago
        The older HiFive Unleashed (1.5 GHz single-issue) builds things considerably faster on a per-core basis than qemu-system on current amd64 (or at least did in the Skylake generation). The dual-issue cores in the HiFive Unmatched should be around 50% faster. 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.
        giantrobot 6y ago
        That's running qemu which is unnecessary for cross compiling. I'm not seeing any advantage to building on native silicon rather than cross compiling on existing machines AMD64 machines. Even with the power usage of the AMD64 chips being higher, the faster compilation speed will likely net less overall energy used for the builds. 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.
    - eclipseo76 6y ago
      > We will likely buy a pile of them to do Fedora builds. Do you expect a lot of things to break on RISCV?
      - brucehoult 6y ago
        Fedora have been shipping on RISC-V for about three years already. Last I saw, around 95% of packages work. The main exceptions have been thing that need some JIT that hasn't been ported yet -- gcc and llvm have been working for years. https://fedoraproject.org/wiki/Architectures/RISC-V 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://buildd.debian.org/stats/graph-ports-week.png
  - caeril 6y ago
    This looks great, thanks!
  - anderspitman 6y ago
    Looks like you can get it from Mouser for $665 as well: https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW32dvEIR3vHEV%2FPYYkdMA%3D%3D https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW3... Found that link from this SiFive page: https://www.sifive.com/boards/hifive-unmatched https://www.sifive.com/boards/hifive-unmatched
tyingq 6y ago
The Rpi4B has a Quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5 GHz with 1MB L2 cache. The A72 claims 4.7 DMIPS/MHz. 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.
- brucehoult 6y ago
  The CPU cores are comparable to the ARM A55, rather than the A72. 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.
  - jgjot-singh 6y ago
    Would this have any sort of meaningful impact on sound/music related processing? E.g I am thinking of vst applications running inside DAWs
    - asd4 6y ago
      On the list of features: "Dedicated Audio Processing DSP and sub-system". 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.

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)?

rwmj 6y ago

Highly unlikely to be very competitive. At this stage it's about getting RISC-V hardware into developers' hands, and previous boards either cost $1000 or were limited in ways where they could not run Linux well. (I am one of the Fedora/RISC-V maintainers.)

deepGem 6y ago
Just saw this SiFive board HiFive is retailing for $679, can you please comment if this is any good for toying around ? Specs look more than decent - almost desktop class computing. https://www.crowdsupply.com/sifive/hifive-unmatched https://www.crowdsupply.com/sifive/hifive-unmatched
- rwmj 6y ago
  I have a couple on order, and I've talked to one of the developers. It looks nice - PCIe, NVRAM SSDs, mini ITX format, 16GB RAM, more cores, etc - but not in the same price point or market segment as an SBC. We will likely buy a pile of them to do Fedora builds.
  - giantrobot 6y ago
    Why would you want use these as build machines? It seems more efficient to just cross-compile on your fastest build machines. You get much faster CI feedback that way. Obviously you want to validate RISC-V code on native devices but using them as builders seems wasteful. 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.
    - FullyFunctional 6y ago
      I'm sure the Fedora builds aren't designed for cross compilation (which is far from trivial for most packages not designed for it). Also, man-power is the most precious resource so it would be a waste to spend time trying to cross-compile what could be built natively.
      - giantrobot 6y ago
        As long as you've got the target toolchain on the host, the code has no idea it's being cross compiled. If you've got the tooling set up it's a lot of setting of envars. It's not trivial but it's also not super difficult. A compiler running native on an architecture doesn't produce any different output than the same compiler doing a cross compilation. 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.
        brucehoult 6y ago
        The older HiFive Unleashed (1.5 GHz single-issue) builds things considerably faster on a per-core basis than qemu-system on current amd64 (or at least did in the Skylake generation). The dual-issue cores in the HiFive Unmatched should be around 50% faster. 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.
        giantrobot 6y ago
        That's running qemu which is unnecessary for cross compiling. I'm not seeing any advantage to building on native silicon rather than cross compiling on existing machines AMD64 machines. Even with the power usage of the AMD64 chips being higher, the faster compilation speed will likely net less overall energy used for the builds. 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.
  - eclipseo76 6y ago
    > We will likely buy a pile of them to do Fedora builds. Do you expect a lot of things to break on RISCV?
    - brucehoult 6y ago
      Fedora have been shipping on RISC-V for about three years already. Last I saw, around 95% of packages work. The main exceptions have been thing that need some JIT that hasn't been ported yet -- gcc and llvm have been working for years. https://fedoraproject.org/wiki/Architectures/RISC-V 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://buildd.debian.org/stats/graph-ports-week.png
- caeril 6y ago
  This looks great, thanks!
- anderspitman 6y ago
  Looks like you can get it from Mouser for $665 as well: https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW32dvEIR3vHEV%2FPYYkdMA%3D%3D https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW3... Found that link from this SiFive page: https://www.sifive.com/boards/hifive-unmatched https://www.sifive.com/boards/hifive-unmatched

tyingq 6y ago

The Rpi4B has a Quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5 GHz with 1MB L2 cache. The A72 claims 4.7 DMIPS/MHz. 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.

brucehoult 6y ago
The CPU cores are comparable to the ARM A55, rather than the A72. 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.
- jgjot-singh 6y ago
  Would this have any sort of meaningful impact on sound/music related processing? E.g I am thinking of vst applications running inside DAWs
  - asd4 6y ago
    On the list of features: "Dedicated Audio Processing DSP and sub-system". 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.