Most of a build was one clang -O2 on one .ll (the game: 32 s of a 41 s headless build, one core). Both paths that assemble - the CLI's (build.ludic: ludicc --emit-llvm, then clang) and ludicc's own (-o, which ludic bundle and the examples use) - now cut the program's IR into N parts with llvm-split (externalizing what the parts share), compile them with one clang each in parallel (-x ir -O<opt> -mmacosx-version-min=11.0, the link's own clang taking the objects where it took the .ll), and remove the parts and objects after. N is $LUDIC_JOBS, else min(cores, free GB / 1.5). It needs an llvm-split and a clang of the same LLVM (Homebrew's LLVM 22 writes attributes Apple's clang 17 cannot read): $LUDIC_LLVM, else /opt/homebrew/opt/llvm/bin. With either missing, on Windows (its shell cannot run the parts at once yet), with LUDIC_SPLIT=0, or when a part fails, it compiles the .ll whole as before. $LUDIC_OPT=1 is a developer's faster build; ludic bundle sets LUDIC_OPT=2 for its compile whatever the shell says. Measured before the compile-only rule (this Mac, 12 cores, one build at a time): - the game headless: 37-41 s -> 13-15.5 s (8 parts / by free memory), peak 2.1 GB -> 1.0-1.1 GB; - the lab headless: 43.1 s -> 12.7 s, peak 2.4 GB -> 1.0 GB; - the game at LUDIC_OPT=1, split: 11.8 s (fps cost not measured). Both built and linked clean; the goldens and a headless shot of the result are not run here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
8.2 MiB
8.2 MiB
| The file is too large to be shown. |