[flang-rt][NFC] Split up expensive .cpp files into multiple files - #198111
Conversation
🐧 Linux x64 Test Results
✅ The build succeeded and all tests passed. |
7877805 to
d55ce26
Compare
Meinersbur
left a comment
Meinersbur
left a comment
There was a problem hiding this comment.
Note that a sequential build will take longer, but IMHO that be well worth it. Do you have numbers on user time in addition to real time (I am curious about the template instantiation cost)?
The result of all of this is that I can now build flang-rt in ~10s
with all threads instead of ~50s due to the most expensive files being
split into parallelizable chunks.
This is only meaningful if you also mention how many threads the the system has.
Summary: This PR simply takes the existing `.cpp` files for the heaviest implementations and separates them logically, typically between real, integer, and complex types. The existing `.cpp` file is turned into a `.h` file and we create new `.cpp` files that *only* contain the old portion that used `RTDEF`. This allows for far more build system parallelism, and it also means that static library linking semantics mean that if the user only uses integer routines the linker will not include the unused complex / real routines in the final executable. All around this is a good practice for runtime libraries. Verified that all `_Fortran` entrypoint routines are still present, port was strictly mechanical. The result of all of this is that I can now build `flang-rt` in ~10s with all threads instead of ~50s due to the most expensive files being split into parallelizable chunks.
The system I tested this on has 48. Agreed on the value, because the overhead associated with launching the compiler a few dozen more times is negligible next to the single-threaded compilation already taking >4 minutes. This was on my machine with a |
|
Thanks for the review. For reference, this is before this PR:| |
…vm#198111) Summary: This PR simply takes the existing `.cpp` files for the heaviest implementations and separates them logically, typically between real, integer, and complex types. The existing `.cpp` file is turned into a `.h` file and we create new `.cpp` files that *only* contain the old portion that used `RTDEF`. This allows for far more build system parallelism, and it also means that static library linking semantics mean that if the user only uses integer routines the linker will not include the unused complex / real routines in the final executable. All around this is a good practice for runtime libraries. Verified that all `_Fortran` entrypoint routines are still present, port was strictly mechanical. The result of all of this is that I can now build `flang-rt` in ~10s with all threads instead of ~50s due to the most expensive files being split into parallelizable chunks.
3 participants
Summary:
This PR simply takes the existing
.cppfiles for the heaviestimplementations and separates them logically, typically between real,
integer, and complex types. The existing
.cppfile is turned into a.hfile and we create new.cppfiles that only contain the oldportion that used
RTDEF. This allows for far more build systemparallelism, and it also means that static library linking semantics
mean that if the user only uses integer routines the linker will not
include the unused complex / real routines in the final executable.
All around this is a good practice for runtime libraries. Verified that
all
_Fortranentrypoint routines are still present, port was strictlymechanical.
The result of all of this is that I can now build
flang-rtin ~10swith all threads instead of ~50s due to the most expensive files being
split into parallelizable chunks.