Содержание
Geekbench разобрал, как работает Intel Binary Optimization Tool (iBOT), и объяснил, откуда берётся прирост до 30% в отдельных подзадачах. По выводам команды, ускорение связано с тем, что iBOT подменяет часть кода на версии с агрессивной векторизацией, то есть сильнее грузит SIMD-инструкции.
Ранее Geekbench уже заявил, что аннулирует результаты, записанные с Core Ultra 7 270K Plus и Core Ultra 5 250K Plus, если тесты шли с включённым iBOT. Причина простая: Geekbench называет себя кроссплатформенным бенчмарком, а iBOT оптимизирует бинарник под конкретную архитектуру Intel и работает далеко не везде.
Что именно нашёл Geekbench в тестах iBOT
В свежем разборе Geekbench оценил эффект iBOT на Geekbench 6.3, запустив тест на ноутбуке MSI Prestige 16 AI+ с процессором Intel Core Ultra 9 386H. В среднем iBOT дал +5,5% и в однопотоке, и в многопотоке.
- Object removal: +24,6%
- HDR processing: +28,5%
Дальше Geekbench копнул именно HDR processing, чтобы понять, что меняет iBOT.
Откуда берутся +28,5%: меньше скаляра, больше вектора
С включённым iBOT Geekbench увидел минус 14% по общему числу исполняемых инструкций и минус 62% по скалярным инструкциям. Зато число векторных инструкций выросло на 1 366%.
Чтобы подтвердить, какие инструкции реально исполняются, команда использовала Intel Software Development Emulator (SDE). После 100 прогонов HDR-субтеста картина получилась такой:
- iBOT выключен: 220 млрд скалярных и 1,25 млрд векторных инструкций
- iBOT включён: 84,6 млрд скалярных и 18,3 млрд векторных инструкций
То есть iBOT переводит заметную часть работы из SISD-логики (скаляр) в SIMD (вектор). На современных CPU это часто даёт хороший прирост без такого же роста энергопотребления, потому что одна инструкция обрабатывает сразу несколько элементов данных.
Почему Geekbench против: «пик вместо типичной производительности»
Geekbench сформулировал претензию жёстко: iBOT «подрывает» идею бенчмарка, потому что заменяет «разнообразный код» на «процессорно-настроенные, полностью оптимизированные бинарники» и тем самым измеряет пиковую, а не типичную производительность. В оригинальной формулировке Geekbench это звучит так: «[iBOT] undermines this by replacing that varied code with processor-tuned, fully optimized binaries, measuring peak rather than typical performance.»
Если перевести на человеческий язык, Geekbench не нравится, что оптимизация включается точечно, под ограниченный список приложений, и делает результаты менее сопоставимыми. Особенно если другие платформы или версии софта такой «подмены» не получают.
Есть и практические минусы. В ранних тестах Geekbench зафиксировал 40 секунд задержки запуска при первом старте с iBOT. Потом задержка стабилизировалась на уровне около 2 секунд. С выключенным iBOT задержки не было.
Ещё один важный момент: Geekbench не увидел прироста в Geekbench 6.7. По данным команды, iBOT сверяет контрольную сумму исполняемого файла. То есть инструмент явно «узнаёт» конкретный бинарник, который он умеет оптимизировать. Любое обновление может этот путь сломать.
Официальные посты Geekbench с объяснением позиции и техническими деталями доступны на сайте проекта: про аннулирование результатов с iBOT и про разбор поведения iBOT.
