3 ms·

I did a comparison of a few RISC-V single board computers and the Lichee Pi 4A is definitely very slow on real world tasks, even though in theory it ought to be

by rwmj 3y ago

I did a comparison of a few RISC-V single board computers and the Lichee Pi 4A is definitely very slow on real world tasks, even though in theory it ought to be the fastest. I never got to the bottom of exactly why - it might be software issues or non-upstream drivers. At the moment I'd recommend the VF2 for general use. https://rwmj.wordpress.com/2023/07/25/heads-up-lichee-pi-4a-vs-visionfive-2-vs-hifive-unmatched-vs-raspberry-pi-4b/ https://rwmj.wordpress.com/2023/07/25/heads-up-lichee-pi-4a-...

edwintorok 3y ago
Interesting, I had the opposite experience: the GUI was very slow and nearly unusable on most RISC-V boards that I have, except the LicheePi4a. But that is probably just due to the GPU (which unfortunately doesn't have open source drivers yet?), and not the CPU, and they're all running different kernels and distros. When I have some time I'll need to compare again with the latest distro available for each, and also a fully open source one.
- sylware 3y ago
  You have to keep in mind that since RISC-V is an ISA standard, C[gcc] coded kernels are here for legacy support purpose. The C[gcc] language is not appropriate anymore, assembly coded is the right(tm) way.
  - CyberDildonics 3y ago
    What is this supposed to mean? You think someone is going to rewrite linux in assembly language?
- snvzz 3y ago
  re: GPU, mesa3d side (vulkan driver) is merged upstream. OpenGL/CL/GLES are via Zink. powervr is working into getting the drm side merged to the kernel, too.
remexre 3y ago
Something's definitely "up with" the RISC-V GCC port; in principle maybe there are just some passes or backend options that need to be flipped on in some way? https://godbolt.org/z/cvc6j1sM6 https://godbolt.org/z/cvc6j1sM6
- camel-cdr 3y ago
  Looks like clang does the optimization for -mno-strict-align, but gcc doesn't seem to support that fully yet: https://godbolt.org/z/xn8erKMTe https://godbolt.org/z/xn8erKMTe Edit: Apparently gcc assumes by default, that unaligned loads aren't supported, but with -mtune=size it somehow enables it: https://godbolt.org/z/d9P19aMnn https://godbolt.org/z/d9P19aMnn some discussion around that: https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=111502 https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id...

by rwmj 3y ago

edwintorok 3y ago

Interesting, I had the opposite experience: the GUI was very slow and nearly unusable on most RISC-V boards that I have, except the LicheePi4a. But that is probably just due to the GPU (which unfortunately doesn't have open source drivers yet?), and not the CPU, and they're all running different kernels and distros. When I have some time I'll need to compare again with the latest distro available for each, and also a fully open source one.

sylware 3y ago
You have to keep in mind that since RISC-V is an ISA standard, C[gcc] coded kernels are here for legacy support purpose. The C[gcc] language is not appropriate anymore, assembly coded is the right(tm) way.
- CyberDildonics 3y ago
  What is this supposed to mean? You think someone is going to rewrite linux in assembly language?
snvzz 3y ago
re: GPU, mesa3d side (vulkan driver) is merged upstream. OpenGL/CL/GLES are via Zink. powervr is working into getting the drm side merged to the kernel, too.

remexre 3y ago

Something's definitely "up with" the RISC-V GCC port; in principle maybe there are just some passes or backend options that need to be flipped on in some way? https://godbolt.org/z/cvc6j1sM6 https://godbolt.org/z/cvc6j1sM6

camel-cdr 3y ago
Looks like clang does the optimization for -mno-strict-align, but gcc doesn't seem to support that fully yet: https://godbolt.org/z/xn8erKMTe https://godbolt.org/z/xn8erKMTe Edit: Apparently gcc assumes by default, that unaligned loads aren't supported, but with -mtune=size it somehow enables it: https://godbolt.org/z/d9P19aMnn https://godbolt.org/z/d9P19aMnn some discussion around that: https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=111502 https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id...