«Немає причин, щоб програмне забезпечення було повільним» — аргумент Дена Лу
Інженер Ден Лу доводить, що робота над продуктивністю, яка раніше вимагала рідкісних фахівців, тепер доступна кожному, хто може написати кілька речень — і це змінює те, які продукти варто створювати.
Роками повільні програми пояснювали економікою експертизи: щоби код був швидким, потрібні були інженери з рідкісними навичками, тож більшість проєктів виходила без оптимізації. Інженер Ден Лу в новому дописі стверджує, що цей компроміс зламався — агентні інструменти знизили вартість оптимізації на кілька порядків.
Аргумент
Допис починається з вірусної тези, що критики «роздутого» коду, який пишуть LLM-моделі, замовкнуть, коли все перепишуть «супероптимізованим асемблером». Лу не заходить так далеко: рукописного асемблера не буде, але оптимізації, які раніше вимагали людини чи команди з рідкісними навичками, тепер доступні кожному, хто вміє надрукувати кілька речень. За його оцінкою, витрати людського часу впали «часто у 1000, 10000 або 1000000 разів», а грошові — приблизно у 1000 разів, якщо порівнювати з інженером Bing, який писав компілятори та JIT-и для пошукового індексу.
Конкретні цифри: regex і ripgrep
Далі — експерименти з FRE, рушієм регулярних виразів, який Лу створив, давши агенту циклічно працювати місяць над набором бенчмарків rebar. Перенавчання було таким сильним, що агенту довелося повідомити про наявність holdout-набору, перш ніж оптимізації узагальнилися. В одному експерименті ripgrep компілював шаблони в нативний код у фоновому потоці й перемикався після завершення компіляції: прискорення у 2–4 рази на кількох довгих простих запитах і близько 7% на репрезентативних holdout-запитах, де застосовний нативний шлях — ціною повільніших коротких запитів.
Софт під одне навантаження
Марк Брукер порівняв тренд із FFTW і трюками демосцени — код, пристосований до однієї конкретної задачі, а не до класу задач, — і передбачив більше «динамічного кастомного софту». Майкл Маліс, який працює над pgrust, додає: мем про те, що «код ніколи не був складним», правильний лише для частини сфер — JIT-компілятори рідкісні, бо їхнє створення було надто дорогим, а бази даних історично були найскладнішим програмним забезпеченням. Лу працював над BitFunnel, пошуковим індексом Bing, який отримав нагороду за найкращу статтю на SIGIR: у версії Bing кілька JIT-компіляторів — масштаб, для якого «зроблю за вихідні» тепер справді правда.
Що не змінюється
Лу говорить і про межі. Оптимізації, що змінюють результат, потребують способу виміряти, чи варта зміна, а сучасні моделі слабкі в дизайні експериментів — тож систему оцінювання досі має будувати людина. Залишається ризик перенавчання: налаштування під одне навантаження ламається, коли навантаження змінюється. А агент, якому просто сказати «оптимізуй», зробить чимало помилок, які треба виловити. Втім, висновок Лу такий: пристойна продуктивність більше не спеціалізована навичка — це розумне очікування для кожного, хто серйозно користується агентами.
SiTech — веброзробка з підтримкою AI
Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.