-
Notifications
You must be signed in to change notification settings - Fork 25
Road Map
- Fix the Building From Source page for
libroadrunner-deps. In particular the part about MC.exe and which branch of libroadrunner-deps to use
We need a better high level overview, as well as a guide about how the roadrunner pipeline works.
We want to decrease the C++ complexity bloat as much possible. Some things are okay like unique_ptr, but in general it's very hard to understand how to safely modify the code. This will be greatly helped by documentation, but we'd also like to make changes to the code to make it more maintainable.
Using a C++ linter will automatically tell you if you violate style guide rules. The Google one is popular, but we may want to use some custom rules.
The code is really hard to understand and navigate right now, because it's not well separated into modules. For example, there are now three main sections of code just looking at files: source/, source/llvm, and source/rr*. In reality, I have no idea if the rr-prefix has any meaning, we should maybe rename those files.
After understanding the code more, I see several modules that should be separated more visibly
- ExecutableModel (containing all LLVM code)
- Integrators
- Python interface (SWIG)
- Testing/CLI
This size of LLVMModelData should not be unknown at compile time as it is now with the data[0] hack. I suggest changing the data fields to a set of pointers to arrays that contain the data
So, I'm not entirely sure how much speedup the LLVMModelData hack gets, in part because I'm not sure how much LLVM code is actually JIT'd and how frequently it interacts with the model data. Either way, the LLVM code is completely frozen until we get some diagnostics about what is actually happening and we can make informed decisions about how to balance between optimization and maintainability.
C++ dependency management sucks, so we're trying to move away from using things like Poco::Variant that we could implement ourselves.
CRTP is used in SetValuesCodeGen, and possibly in other places. I would like to investigate if we could get the same performance out of some other, more readable design. It's only used in like 3 files, but those files are frequently hotspots for debugging and it takes a lot of effort to understand what is going on. At the very least, they should be better documented and explain CRTP.
NOTE: Rust can do CRTP automatically thanks to type inference. Check out an example of explicit CRTP in C++ vs implict CRTP in Rust both on -O2. (You may have to turn demangle off to prove that it's calling different interface()s). In summary, C++ cannot ever implicitly do CRTP, whereas Rust can.
- Direct access to the model data to change it during execution
There are a lot of problems with C++ that might be solved by moving to a language like Rust. I'm interested in experimenting with this by taking small pieces of the codebase and replacing them with Rust equivalents. This would involve setting up a build/link system with cargo in CMake, but that's doable.