Assessment of the difficulty in porting CPU architecture for vc

[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 vc 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 moderate leaning towards simple, with a moderate amount of code related to the CPU architecture in the project. Is this assessment accurate?Do you often have any opinions on personnel allocation and consumption time？ I look forward to your help and response.

[bernhardmgruber]

As a general comment, the less your code depends on CPU architecture specifics the easier it is to port. For example, my LLAMA library only required a single change in the CMakelists.txt (removing -march=native) to successfully compile and run the unit tests on the VisionFive 2 board. This was easy because the library tries very hard to be written entirely in standard C++. The Vc library on the contrary, and by design, contains a LOT of CPU architecture specific code, mostly SIMD intrinsics. For that matter I estimate the porting difficulty to a new architecture as extremely difficult and requiring expert knowledge on SIMD for RISC-V. Which is additionally problematic, since AFAIK the SIMD ISA for RISC-V, the V extension, has only been frozen a few years ago and hardware implementing it is rare. I also don't know how far compiler support has come. So it may even be the case that a port of Vc to RISC-V is still impossible.