CI: 4h -> 2h (40 min with cache)

[kimstik]

While working on #226 I waited four hours for every CI run of the bindings, most of it on steps that repeat the same work. The same jobs now take about 1h50 from scratch and 37 minutes when the object cache hits, on the same free runners. Six commits, one idea each:

• N_PROC defaults to the machine's cores instead of 2. -DN_PROC still overrides.
• pywrap: PCH of the shared preamble, symbol lookup by bisection, smaller collections chunks. Generation on Linux takes 12 minutes instead of 49.
• The OSX bindings are generated on Linux like the Windows ones, 15 minutes instead of 2h49. Same sources as a native run.
• PYTHONHASHSEED=0 for bindgen: the generation is reproducible. Two runs give byte-identical sources, so builds can be diffed.
• Compile with four jobs on every platform, possible once the collections chunks shrank from 5 to 3.2 GB.
• sccache on the GitHub Actions cache: unchanged sources compile in minutes. Bump SCCACHE_GHA_VERSION to start empty.

	before (min)	after, empty cache	after, cache hits
Generate Linux / Windows / OSX	49 / 34 / 2h49	12 / 14 / 15	same
Compile Linux / Windows / OSX	1h17 / 2h05 / 54	1h04 / 1h21 / 60	2 / 3 / 4
whole run	4h02	~1h50	37 min

Also fixed:

• OSX was compiled at -O0 and without the SDK. A space after a line continuation in Compile (Mac).
• The Windows bindings lacked the members new in occt 8.0.1. The symbols had been dumped from 8.0.0.
• The generated sources changed from run to run with the hash seed, down to one V3d_ImageDumpOptions member that came and went.
• pywrap: the default args list of parse_tu grew with every call.

Depends on CadQuery/pywrap#66.

[adam-urbanczyk]

Thanks, but this has too much stuff at once. To begin with, do you know what is the impact of PCH?

[kimstik]

Thanks, but this has too much stuff at once. To begin with, do you know what is the impact of PCH?

The most visible impact is roughly 2h back on every CI run ;)

As for the PCH itself, it is on the pywrap side (CadQuery/pywrap#66). This PR only moves the submodule.
I tried a PCH for the compilation as well. It made no measurable difference, so I left it out.

Every header re-parsed the same preamble: parsing_header, the platform header, Standard_Handle.hxx and its includes.
With the preamble parsed once per worker, parsing takes 10 minutes instead of 32 on each platform.
The generated sources stay the same.

Risk-wise: the PCH is built per process in a temporary directory, keyed on the arguments and the preamble text, so nothing stale can be picked up between runs.
It is one function in translation_unit.py and easy to revert.

The commits are the smallest set I could get, one idea each and in dependency order, to keep each step reviewable on its own.
Split into separate PRs, I am afraid they would lose the logic that ties them together.

@adam-urbanczyk, would you rather have them as separate PRs?

[adam-urbanczyk]

No need for separate PRs, I'm just curious how much gain comes from the PCH trick and how much from effectively increasing the N_PROC to 4.

[kimstik]

No need for separate PRs, I'm just curious how much gain comes from the PCH trick and how much from effectively increasing the N_PROC to 4.

Roughly half each, on the Linux generation (4-core GitHub CI runner):

N_PROC 2 -> 4: 49 -> 27 min. Not 2x, because the modules differ a lot in size and the transform step is single-threaded.
PCH on top: the parse goes from about 31 to 10 min, the whole step to 12 min.

The difference is in kind: N_PROC spreads the same work over the cores, the PCH removes about two thirds of the parsing work.
Single runs, and runner speed varies by up to 1.5x, so take the numbers as rough.