Skip to content

compilation: stop pinning aiecc to one thread - #185

Open
atassis wants to merge 1 commit into
amd:develfrom
atassis:pr/aiecc-jobs-default
Open

compilation: stop pinning aiecc to one thread#185
atassis wants to merge 1 commit into
amd:develfrom
atassis:pr/aiecc-jobs-default

Conversation

@atassis

@atassis atassis commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Problem

Both aiecc rules default AIECC_JOBS to 1:

options = [f"-j{os.environ.get('AIECC_JOBS', '1')}"]

so every design's per-core compiles run one at a time, whatever the machine has. aiecc's own default
is auto-detect, and nothing here explains the override.

Fix

Default to 0, which is aiecc's auto-detect. The environment variable still overrides, so anyone who
wants one thread keeps it.

Test

On a 24-core design (StaticMHA, 20 heads, 8 pipelines): aiecc goes from 7.7 s to 6.0 s. Nothing
above 8 threads helps.

-j does not change what aiecc produces, so this is safe rather than a trade: insts.bin and all 24
per-core ELFs are byte-identical between -j1 and -j16, and input_with_addresses.mlir differs
only in the work-dir path it embeds — which two runs at the same -j also differ in.

Both aiecc rules defaulted AIECC_JOBS to 1, so every design's per-core compiles
ran serially. On the encoder-MHA design (24 cores) that is 7.7 s against 6.0 s
at aiecc's own auto-detect; nothing above 8 helps. -j does not change the
output: insts.bin and all 24 per-core ELFs are byte-identical between -j1 and
-j16.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant