Реестр оптимизации: бюджет кадра вырос втрое, срочность позиций падает

This commit is contained in:
2026-08-19 23:23:22 +03:00
parent 35d7bd38d4
commit 5d61224229
+18
View File
@@ -851,3 +851,21 @@ Apple II и по комментариям вида «DOS PoP does this» в са
**Что проверять в первую очередь при новом «дорогом» месте:** не сколько **Что проверять в первую очередь при новом «дорогом» месте:** не сколько
там арифметики, а сколько раз за кадр пересекается граница банка. там арифметики, а сколько раз за кадр пересекается граница банка.
## Фиксированный логический кадр (2026-08-19) — МЕНЯЕТ ВСЕ ЦЕЛЕВЫЕ ЧИСЛА
Период логического кадра больше не `ceil(W) + 2`, а `max(n, ceil(W))`
(`roomtest/pop_pace.c`, разбор — `frame_pacing_plan.md`). Поэтому:
- **Бюджет кадра вырос с 430 080 до 1 290 240 тактов** (n = 3, режим
FASTEST по умолчанию). Все записи этого реестра, где «работа сверх
430 000 стоит сразу целого растра», СЧИТАТЬ УСТАРЕВШИМИ.
- 13/23 (максимум работы 911 862) теперь укладывается в период 3 растра —
проверено, ни одного кадра длиннее. Прежний профиль был 3/4/5.
- Оптимизация из спешной стала плановой: смысл резать такты остался
(режим NORMAL при n=4 и бой при n=5 дают ещё больше запаса, а FASTEST —
верхнюю планку скорости), но «свалиться за растр» больше не обрыв.
- Цена самого пейсинга — ≈4 000 тактов на кадр (0,9 %), замерено A/B.
Приоритет P9 (G8) и остальных позиций от этого не меняется, но их
СРОЧНОСТЬ падает: они больше не спасают от скачка периода.