mglisse
commented
1 year ago CGAL should work as is on RISC-V (though I don't know if anyone has tried), it has generic code for unknown architectures. Some knowledge of how CGAL works and of RISC-V could help improve performance. Just to give an idea, in order from simplest to most advanced:
- IA_opacify in FPU.h: just needs the name used for FP registers in inline asm, and the macro to recognize RISC-V
- CGAL_IA_ADD, etc: use the instructions with static upwards rounding, and drop the calls to fesetround.
- vector version of interval arithmetic (we only have one for x86_64)
Except for the first one, those are only worth the trouble if several users/customers really need the last bit of performance. There may be other parts that could be improved for specific architectures, but again things should just work without any porting (assuming dependencies like boost, gmp, eigen, etc all already work).
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, it can be estimated on average across various architectures.I would like to gather community opinions to support my assessment.As part of my dataset, I have collected the CGAL project. By using scanning tools, I have determined that the porting complexity is high due to a moderate amount of code related to the CPU architecture. It would require a professional one to handle this task. (referring to the overall workload from adapting the project to a specific architecture to achieving full functionality on that architecture)Is this assessment accurate? I look forward to your help and response.