Compiler: enable parallel codegen with MT #14748
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jun 25, 2024
|
This looks great. But it also seems to be a mix of different changes. Could we extract the independent refactorings (such as extracting |
We only need to update unit.reused_compilation_unit? from forked process then have print_codegen_stats count & filter the units.
When compiled with -Dpreview_mt the compiler will take advantage of the MT environment to codegen the compilation units in parallel, avoiding fork (that's not supported with MT) and allowing parallel codegen on Windows.
ysbaddaden
force-pushed
the
feature/compiler-mt-codegen-2
branch
from
3a08d9e
to
ac91f7c
Compare
|
Rebased on top of #14760. |
Sija
reviewed
Jul 2, 2024
Comment on lines
+550
to
+559
| # We generate the bitcode in the main thread because LLVM contexts | ||
| # must be unique per compilation unit, but we share different contexts | ||
| # across many modules (or rely on the global context); trying to | ||
| # codegen in parallel would segfault! | ||
| # | ||
| # Luckily generating the bitcode is quick and once the bitcode is | ||
| # generated we don't need the global LLVM contexts anymore but can | ||
| # parse the bitcode in an isolated context and we can parallelize the | ||
| # slowest part: the optimization pass & compiling the object file. | ||
| unit.generate_bitcode |
There was a problem hiding this comment.
Perfect example: behavior is so odd, document it, otherwise it will be incomprehensible.
ysbaddaden
commented
Jul 2, 2024
| private def compile_to_object | ||
| temporary_object_name = self.temporary_object_name | ||
| target_machine = compiler.create_target_machine | ||
| compiler.optimize llvm_mod, target_machine unless compiler.optimization_mode.o0? |
There was a problem hiding this comment.
This line above may be what fixed the LLVM segfault compared to the previous attempt: the target machine is local to the compilation unit, since as found out by @ggiraldez in #14496 (comment) the target machine itself is thread unsafe (not just the llvm context).
ysbaddaden
commented
Jul 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements parallel codegen of object files when MT is enabled in the compiler (
-Dpreview_mt).It only impacts codegen for compilations with more than one compilation unit (module), that is when neither of
--single-module,--releaseor--cross-compileis specified. This behavior is identical to the fork based codegen.Advantages:
The main points are increased portability and simpler logic, despite having to take care of LLVM thread safety quirks (see comments).
Issues:
The
threadsarg actually depicts the number of fibers, not threads, which is confusing and problematic: increasingthreadsbut notCRYSTAL_WORKERSwill lead to more fibers than threads, with fibers being sheduled on the same threads, which won't bring any improvement.In fact
CRYSTAL_WORKERSdefaults to 4, whenthreadsdefaulted to 8. With this patch it defaults toCRYSTAL_WORKERS, so MT can end up being slower if we don't specifyCRYSTAL_WORKERS=8.This is still not as efficient as it could be. The main fiber (that feeds the worker fibers) can get blocked by a worker fiber doing codegen, leading the other workers to starve. This is easily noticeable when compiling with
-O1for example.Both issues will be fixable with RFC 2 where we can start an explicit context to run the worker fibers or start N isolated contexts (maybe a better idea). Until then, one should increase
CRYSTAL_WORKERS.Supersedes #14227 and doesn't segfault (so far) with LLVM 12 or LLVM 18.1 🤞
TODO:
mt_parallel(units, n_threads)CRYSTAL_CONFIG_WORKERSto configure the default number of workers at compile time instead of the hardcoded 4 (in a distinct PR)