Files
Nim/compiler
araq 8299401888 IC: render every module's .c in one emit process
`emit` is the one backend stage with nothing to get wrong. It loads no
module graph — it derives its output path rather than resolving it — and
`renderCFromArtifact` filters text against the merge decision without
touching an AST. It is a pure function of one `.c.nif` and one global
artifact, so grouping the calls cannot change what comes out.

Measured rather than assumed: 67 separate emit processes and one process
with all 67 members produce byte-identical `.c`, in 0.502 s against
0.041 s. So emit takes a single nifmake rule covering every live module.

Where that shows up is narrower than the 12x suggests. Cold serial 8.21 s
-> 7.82 s; cold parallel 2.81 s -> 2.83 s, i.e. nothing, because 0.46 s
spread over 16 cores is already invisible. An edit to `system.nim` is
2.15 s either way: emit was never what made that slow. The honest case is
CPU rather than wall clock, plus one fewer thing to pay for on a machine
that is not idle — the fire-all is structural (every `emit` re-fires
whenever `merge` rewrites the decision, by design) and now costs one
process start instead of 67.

Also fixes a bug this exposed: `isMain` was a per-BATCH flag. That is the
right question for `lower`/`cg`, where main loads the whole program and
is never batched with anything, but emit batches freely — and main in a
mixed batch had its `.c` path derived from its module SUFFIX instead of
its source file, so it was never written at all.

`-d:icBatchSize:N` still splits emit the old way, for comparing against
the fan-out. ic 40/40, `koch boot -d:release` equal executables, and the
67 generated `.c` are byte-identical to the previous commit's.
2026-08-31 13:59:46 +02:00
..
2026-06-11 14:10:42 +02:00
2026-02-10 13:21:35 +01:00
2026-06-25 23:20:34 +02:00
2026-08-27 19:35:11 +02:00
2017-01-07 22:35:09 +01:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2025-12-11 18:22:38 +01:00
2026-08-27 19:35:11 +02:00
2026-07-03 15:52:41 +02:00
2026-07-04 10:13:39 +02:00
2025-11-25 12:49:23 +01:00
2026-08-17 15:02:49 +02:00
2024-12-27 19:42:18 +01:00
2026-06-14 22:35:06 +02:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2026-04-02 07:19:43 +02:00
2026-06-14 22:35:06 +02:00
2026-06-25 23:20:34 +02:00
2021-01-12 09:36:51 +01:00
2026-08-27 19:35:11 +02:00
2026-01-09 13:10:04 +01:00
2026-06-14 22:35:06 +02:00
2026-08-17 15:02:49 +02:00
2026-07-03 15:52:41 +02:00
2026-08-27 19:35:11 +02:00
2026-06-24 21:58:51 +02:00
2025-12-11 18:22:38 +01:00
2026-08-17 15:02:49 +02:00
2026-06-14 22:35:06 +02:00
2026-08-17 15:02:49 +02:00
2026-02-10 13:21:35 +01:00
2026-08-17 15:02:49 +02:00
2023-07-02 22:36:05 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-11 22:27:49 +02:00
2025-12-11 18:22:38 +01:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2026-08-27 19:35:11 +02:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-06-24 21:58:51 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2023-12-25 07:12:54 +01:00

Nim Compiler

  • This directory contains the Nim compiler written in Nim.
  • Note that this code has been translated from a bootstrapping version written in Pascal.
  • So the code is not a poster child of good Nim code.

See Internals of the Nim Compiler for more information.