Assessment of the difficulty in porting CPU architecture for libceed

[wangyuliu]

Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting. In fact, the tool may have an average estimate of various architecture porting efforts.My focus is on the overall workload and difficulty of transplantation in the past and future,even if a project has already been ported.As part of my dataset, I have collected the libceed project. I would like to gather community opinions to support my assessment. I appreciate your help and response! Based on scanning tools, the porting complexity is determined to be simple, with a small amount of code related to the CPU architecture in the project. Is this assessment accurate?Do you often any opinions on personnel allocation and consumption time？ I look forward to your help and response.

[jeremylt]

I don't know a ton about RISC-V. If the environment has a C99 compiler, then libCEED should build fine. There are a couple of macros that might need to be updated if the compiler is different than the ones we regularly test with (GCC, Clang, Intel).

The CPU architecture specific code is limited to optional backends that provide faster tensor contractions on the hardware (AVX or SVE for example). Id be open to creating a backed for RISC-V, if such a thing makes sense and there's a way to test such code via GitHub Actions or similar.

[jedbrown]

Yeah, I'd expect RISC-V compilation to work out of the box, albeit with performance limited by compiler auto-vectorization. For high performance, you could look at libCEED's avx backend and consider doing similar for a zve backend. Alternatively, there could be a backend using gcc/clang vector intrinsics (instead of the current approach of architecture-specific intrinsics). There are a variety of strategies that would be possible in this space.