[victor-ab]

Motivation

After the stack's first PR, the rank tables' exceptions are the largest part of a categorical model's loaded heap: 8 bytes each, [slot, word] with an absolute 32-bit slot. A feature's slots are its own contiguous range, almost always far fewer than 65,536, and the fill's restore loop reads only the slots.

Design

layout: separate exception words from feature-relative slots

• BinMap keeps the exceptions' words and their slots in separate arrays, the slots relative to their feature's first slot.
• The slots are 16 bits wide while every categorical feature's slots fit (a relative slot below 65,536). The first feature that doesn't converts the slots so far to 32 bits once, model-wide, and the build continues in 32 bits, so no model that loads today fails to load; there is no transient double copy in the common case.
• fill_with dispatches on the width once per feature, then runs a monomorphic loop; the restore loop reads 2 bytes per exception rather than 8.
• rank_table_bytes counts 6 bytes per exception (8 in the 32-bit fallback), and the cap is checked on the same count, including a widening, before the tables grow; so LoadOptions::max_rank_table_bytes counts what is held, as the cap table in docs/treelite-loading.md says. A model near the cap that failed before can now load; none that loaded fails.

Evidence

On the private model, the loaded model's heap is 14% lower than with #66 (41% of 3.2.2's), and outputs are bitwise equal to 3.2.2's on synthetic rows and on the generated requests.

Latency, predict_fixed per request on the generated requests, one thread, Apple M4 Pro: p50 change from #66, median of four paired rounds (A B B A, 1 s per cell), with the rounds' range:

	1 candidate	32	512
this PR vs #66	+1.3% (+0.8 to +1.9)	within noise (−7.3 to +4.1)	within noise (−13.0 to +5.7)

On AVX-512 (GCP c4-standard-8, Intel Xeon Platinum 8581C, SMT off, all-core turbo, one pinned core; six paired rounds), for the served requests and for groups of 128 to 1,024 rows (max_group_width 1024): like any group of 65 to 1,024 rows, these take Handle carriers and reach list_avx512:

	1 candidate	32	512	128 rows	512 rows	1,024 rows
this PR vs #66	−5.5% (−5.9 to −5.1)	−5.7% (−8.6 to −4.5)	−6.4% (−8.0 to −5.4)	−1.2% (−1.6 to −0.4)	−1.5% (−2.2 to −1.3)	−3.8% (−5.1 to −3.3)

The M4's 1-candidate cost doesn't carry over: on AVX-512 the narrower slots are faster at every size.

Where the rounds disagree in sign, only their range is given.

• Tests: the width boundary (65,536 slots stays narrow, 65,537 widens) and a widening keeping the earlier entries; fills after a widening keep the earlier features' words; a model whose unpacked chains need 32-bit slots predicts as its packed layout does, with constant and varying features. Expectations in tests/import.rs, tests/limits.rs and tests/research.rs are recomputed for 6-byte entries.
• cargo test --release --features research passes; clippy (workspace, research, library alone) and fmt.

[ukaratay]

Approving. I checked the width boundary (65,536 slots stay 16-bit, 65,537 widen) and that the cap counts a widening before the tables grow. The +1.3% at 1 candidate shows up in every round, so it's a real cost. That's fine for 14% of the loaded heap, but it adds to the x86 question on #74.

[victor-ab]

On AVX-512 this PR is faster at every size: −5.5%, −5.7% and −6.4% at 1, 32 and 512 candidates, and −1.2% to −3.8% on groups of 128 to 1,024 rows (GCP c4, six paired rounds). Details are on #74.