Idea: ship play profiles (the hot list and the renderer's profile) with releases #505

New issue

Open

opened 2026-11-14 17:33:51 +00:00 by HumanBean · 1 comment

HumanBean commented

2026-11-14 17:33:51 +00:00

Owner

The idea

Longshot already has everything needed to build the hottest lifted game functions at -O2 with a play profile, but releases don't ship with it, so every player's build compiles all of the lifted code at -O1.

What exists today

scripts/hotlist.py turns a sampled play session (HOS_SAMPLE_ALL) into hot_funcs.txt: the lifted functions that make up the first 85 % of samples, hottest first, capped at 1,500, plus the game's Zstd decoder.
nx2/split_hot.py puts those functions into eight hot pieces compiled at -O2 with the play profile (RX_PGO, fitted to the pieces by nx2/pgo_pieces.py).
scripts/tools.py assemble profile packs the list and the profile for a release (RELEASING.md). make_game.py uses them when work/ has them.
Releases ship neither: tools.lock has no profile line ("No play profile yet").

What it buys and what it costs

With today's list, the 85 % cut comes to about 850 functions (849). Measured against main 0caf0618, the whole build before shaders:

	Ryzen 9 7900X, 12 pinned threads	i7-9700K, 6 jobs
No hot list	9:04	19:32
All 849 at -O2 + profile	10:34, +17 %	23:18, +19 %
First 300 at -O2 + profile	not built	21:22, +9 %
First 300 at -O1 + profile	not built	20:57, +7 %

The gain is small. All 849 gave about +3 % fps walking in the Market (RTX 3090: 16.54 → 15.96 ms, 4 sessions each). Standing still showed nothing.
The lab couldn't show it. On the i7-9700K with an RX 580 the game is GPU-bound and its sessions vary by ±2 ms.
A shorter list keeps most of it. The first 300 functions cover 83 % of what the 849 cover on the Market walk, with 58 % of the code. That is about a 70 % share instead of 85 %. The gain is expected to scale with coverage, so roughly +2.5 % fps. That's an estimate: 300 hasn't been measured on a CPU-bound PC.
PR 385 (merged) changes the trade. It cut a first build's compile by about 21 % on a 6-core PC, so a +9 % list still leaves players' builds faster than before 385. It leaves the hot pieces whole on purpose, so they may become the build's longest files; this needs one build with both to check.

The proposal: generate the list before each release and ship it

Make the list from Longshot itself. The list and profile in hand were made by Hookshot, on a route nobody recorded. Record them from Longshot's own lifter over a broad route rather than one area. The pipeline tour (PR 111) would give the same route every time.
Cut it at about 70 % instead of 85 %, for about 300 functions and +9 % build time. A fixed count (hotlist.py <run> <out> 1.0 300) keeps the build cost the same from one release to the next; a share gives a different count on every session.
Ship it with the release: tools.py assemble profile, tools.py add, and the profile line in tools.lock.
Re-record it when the lifter's output changes. The profile's counts are tied to the lifted C. The list names guest addresses, so it only needs to change with the game version or when functions stop being lifted code.
Maybe: an option in the launcher (a faster build vs. a faster game, such as 100 / 300 / 500 functions). Against that: it's a knob for a few percent, and each choice is another binary to support. The builder could instead choose by the PC (more threads, a longer list).

The renderer's play profile

The renderer (our own Vulkan code, gpu/vk/) can be built with a play profile of its own, and that helps more than the hot list does, at almost no build cost.

What it is: a counting build of the renderer (RX_VK_PGO=gen), a session played with it, then the renderer built with the counts (RX_VK_PGO=<file>). It's ported from ProjectReLink, on the local branch build/vk-pgo, not pushed yet. The renderer needs no hot list: it's small enough to build whole with the profile.
What it buys: on a Ryzen 9 7900X with an RTX 3090, from the Market save, main against main with the renderer built with the profile. Median frame:

Standing Running in the square

-O2 13.53 / 13.49 / 13.70 ms 15.89 / 16.13 / 15.73 ms

-O2 + profile 12.96 / 13.37 / 12.94 ms 15.13 / 15.67 / 15.52 ms

That's about -4 to -5 % standing and -3 % running. -O3 and link-time optimisation added nothing on top in a first screening.
What it costs: almost no build time. Players already compile the renderer (about a minute of one compile job), and the profile only changes how. No prebuilt renderer is needed: the release ships the profile file and the builder uses it.
Still to settle:
- Record it over a broad route rather than one area. The one measured was recorded on the same Kokiri-to-Market route it was measured on.
- Record each GPU path: mesh shaders and the compute fallback, merged into one file.
- Probably one profile per platform, since the Windows and Linux builds use different standard libraries. Linux's could be tried on Windows first.
- The profile writer has only run on Linux.
- Re-record it as the renderer changes. A stale profile only loses gain where code changed.

	Standing	Running in the square
-O2	13.53 / 13.49 / 13.70 ms	15.89 / 16.13 / 15.73 ms
-O2 + profile	12.96 / 13.37 / 12.94 ms	15.13 / 15.67 / 15.52 ms

Both profiles would ship the same way: in the play profile bundle (tools.py assemble profile) and the profile line in tools.lock.

Related

PR 30 keys the hot pieces by the profile's contents instead of its path. It should land first or with this: without it, every new checkout or launcher channel compiles the eight hot pieces again, and the object store (PR 371) can't share them.

Anything else

The play profile holds addresses and counts only, no game data; the owner has approved publishing it. Measurements and scripts are on the PC that made them, and they can be added here.

🤖 Generated with Claude Code

### The idea Longshot already has everything needed to build the hottest lifted game functions at `-O2` with a play profile, but releases don't ship with it, so every player's build compiles all of the lifted code at `-O1`. **What exists today** - `scripts/hotlist.py` turns a sampled play session (`HOS_SAMPLE_ALL`) into `hot_funcs.txt`: the lifted functions that make up the first 85 % of samples, hottest first, capped at 1,500, plus the game's Zstd decoder. - `nx2/split_hot.py` puts those functions into eight hot pieces compiled at `-O2` with the play profile (`RX_PGO`, fitted to the pieces by `nx2/pgo_pieces.py`). - `scripts/tools.py assemble profile` packs the list and the profile for a release (RELEASING.md). `make_game.py` uses them when `work/` has them. - Releases ship neither: `tools.lock` has no `profile` line ("No play profile yet"). **What it buys and what it costs** With today's list, the 85 % cut comes to about 850 functions (849). Measured against main 0caf0618, the whole build before shaders: | | Ryzen 9 7900X, 12 pinned threads | i7-9700K, 6 jobs | |---|---|---| | No hot list | 9:04 | 19:32 | | All 849 at -O2 + profile | 10:34, **+17 %** | 23:18, **+19 %** | | First 300 at -O2 + profile | not built | 21:22, **+9 %** | | First 300 at -O1 + profile | not built | 20:57, +7 % | - **The gain is small.** All 849 gave about +3 % fps walking in the Market (RTX 3090: 16.54 → 15.96 ms, 4 sessions each). Standing still showed nothing. - **The lab couldn't show it.** On the i7-9700K with an RX 580 the game is GPU-bound and its sessions vary by ±2 ms. - **A shorter list keeps most of it.** The first 300 functions cover 83 % of what the 849 cover on the Market walk, with 58 % of the code. That is about a 70 % share instead of 85 %. The gain is expected to scale with coverage, so roughly +2.5 % fps. That's an estimate: 300 hasn't been measured on a CPU-bound PC. - **[PR 385](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/385) (merged) changes the trade.** It cut a first build's compile by about 21 % on a 6-core PC, so a +9 % list still leaves players' builds faster than before 385. It leaves the hot pieces whole on purpose, so they may become the build's longest files; this needs one build with both to check. **The proposal: generate the list before each release and ship it** 1. **Make the list from Longshot itself.** The list and profile in hand were made by Hookshot, on a route nobody recorded. Record them from Longshot's own lifter over a broad route rather than one area. The pipeline tour ([PR 111](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/111)) would give the same route every time. 2. **Cut it at about 70 % instead of 85 %**, for about 300 functions and +9 % build time. A fixed count (`hotlist.py <run> <out> 1.0 300`) keeps the build cost the same from one release to the next; a share gives a different count on every session. 3. **Ship it with the release:** `tools.py assemble profile`, `tools.py add`, and the `profile` line in `tools.lock`. 4. **Re-record it when the lifter's output changes.** The profile's counts are tied to the lifted C. The list names guest addresses, so it only needs to change with the game version or when functions stop being lifted code. 5. **Maybe: an option in the launcher** (a faster build vs. a faster game, such as 100 / 300 / 500 functions). Against that: it's a knob for a few percent, and each choice is another binary to support. The builder could instead choose by the PC (more threads, a longer list). ### The renderer's play profile The renderer (our own Vulkan code, `gpu/vk/`) can be built with a play profile of its own, and that helps more than the hot list does, at almost no build cost. - **What it is:** a counting build of the renderer (`RX_VK_PGO=gen`), a session played with it, then the renderer built with the counts (`RX_VK_PGO=<file>`). It's ported from ProjectReLink, on the local branch `build/vk-pgo`, not pushed yet. The renderer needs no hot list: it's small enough to build whole with the profile. - **What it buys:** on a Ryzen 9 7900X with an RTX 3090, from the Market save, main against main with the renderer built with the profile. Median frame: | | Standing | Running in the square | |---|---|---| | -O2 | 13.53 / 13.49 / 13.70 ms | 15.89 / 16.13 / 15.73 ms | | -O2 + profile | 12.96 / 13.37 / 12.94 ms | 15.13 / 15.67 / 15.52 ms | That's about **-4 to -5 % standing and -3 % running**. -O3 and link-time optimisation added nothing on top in a first screening. - **What it costs:** almost no build time. Players already compile the renderer (about a minute of one compile job), and the profile only changes how. No prebuilt renderer is needed: the release ships the profile file and the builder uses it. - **Still to settle:** - Record it over a broad route rather than one area. The one measured was recorded on the same Kokiri-to-Market route it was measured on. - Record each GPU path: mesh shaders and the compute fallback, merged into one file. - Probably one profile per platform, since the Windows and Linux builds use different standard libraries. Linux's could be tried on Windows first. - The profile writer has only run on Linux. - Re-record it as the renderer changes. A stale profile only loses gain where code changed. Both profiles would ship the same way: in the play profile bundle (`tools.py assemble profile`) and the `profile` line in `tools.lock`. **Related** - [PR 30](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/30) keys the hot pieces by the profile's contents instead of its path. It should land first or with this: without it, every new checkout or launcher channel compiles the eight hot pieces again, and the object store ([PR 371](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/371)) can't share them. ### Anything else The play profile holds addresses and counts only, no game data; the owner has approved publishing it. Measurements and scripts are on the PC that made them, and they can be added here. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

HumanBean referenced this issue

2026-11-14 17:46:44 +00:00

Idea: ship hot lists with releases #507

HumanBean referenced this issue

2026-11-14 17:46:44 +00:00

Idea: ship hot lists with releases #514

HumanBean referenced this issue

2026-11-14 17:46:44 +00:00

Idea: ship hot lists with releases #525

HumanBean changed title from ~~Idea: ship hot lists with releases~~ to Idea: ship play profiles (the hot list and the renderer's profile) with releases

2026-11-14 18:21:28 +00:00

HumanBean referenced this issue

2026-11-14 20:04:38 +00:00

perf(vk): the renderer is built with a committed play profile, about 3-5 % less frame time #569

HumanBean referenced this issue

2026-11-14 20:13:29 +00:00

chore(release): play profiles are committed in assets/profiles/, not a tools.lock archive: tools.py assemble profile removed #572