Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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-...



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.


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.


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.


What is this supposed to mean? You think someone is going to rewrite linux in assembly language?


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


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

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

some discussion around that: https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: