Почему программное обеспечение больше не должно быть медленным

Я работал над похожим агентически спроектированным regex-проектом под названием SafeRE:

https://github.com/eaftan/safere

https://eaftan.github.io/safere-intro/

Мой проект предназначен для Java и рассчитан на продакшн-уровень. Первая цель — гарантировать линейное время выполнения для предотвращения ReDoS-атак. Мы с коллегой недавно оптимизировали его, пытаясь превзойти нативный RE2 по производительности.

Оказывается, оптимизации невероятно хорошо подходят для агентного цикла. У вас есть конкретные критерии приёмки (должно показать значимое улучшение на бенчмарк-кейсе, должно пройти тесты). Агент действительно, действительно хорош в использовании таких инструментов, как профилировщик и дизассемблер, лучше, чем я (а я занимаюсь этим 20 лет). Он также скрывает вещи, на изучение которых у меня ушло бы время, например, как работает инкубационный Vector (SIMD) API в Java. Я понимаю концепцию, но мне потребовалось бы время, чтобы разобраться в реализации Java. Агент может просто прочитать документацию и работать.

Ключ в том, чтобы создать хороший набор бенчмарков и убедиться, что агент не выпускает оптимизации, которые слишком узкие или слишком сфокусированы на бенчмарк-кейсах. Также нужен очень сильный набор тестов, чтобы убедиться, что вы не регрессируете в корректности. У SafeRE миллиарды тестов; подмножество в несколько миллионов запускается в CI, а остальные — по требованию.

Вот суть:

> Стохастический процесс поиска с исполняемой целью оптимизации в пространстве программ S может только поддерживать или улучшать эту цель.

Это супероптимизация. Мы знаем об этом с 80-х (Massalin, STOKE — более свежий пример: https://github.com/StanfordPL/stoke). Единственная новизна в том, что теперь предлагающий стал намного лучше с помощью языковых моделей.

Более того, существует множество причин, по которым ПО, написанное агентами, может быть медленным:

- Языковые модели всё ещё плохо справляются с проектированием, ориентированным на данные или оборудование, из коробки, и поэтому, если вы занимаетесь серьёзной новой работой, выходящей за рамки переноса очень хорошо понятной программы с очень хорошо понятными рабочими нагрузками, вы будете тратить часы на отслеживание плохих решений по выделению памяти (ср. почему TigerBeetle не использует агентов), которые часто являются корнем зла (прежде чем вы обратитесь к чему-то ещё).

- Ручки, которые нужны для достижения серьёзной производительности, почти недостижимы в языках, в которых хороши языковые модели (даже Rust требует дисциплины, которую язык по умолчанию не обеспечивает). Когда вы опускаетесь на более низкие уровни, вы обмениваете контекст потребления на доступ к этим рычагам. Рычаги также "мягкие": вы обнаруживаете, что пишете множество навыков и инструментов, чтобы попытаться обеспечить эту дисциплину.

Реальность такова: чтобы получить производительный код (быстро) от агента, вам нужно знать, как писать производительный код (и вам нужно знать, как вывести информацию, которую вы бы использовали для создания верификатора для такого кода, на […]

«Языковые модели приводят к медленному, раздутому коду — они будут посрамлены, когда всё перепишут на супероптимизированном ассемблере».

Этот человек не понимает, как создавать эффективный код. Я могу писать код почти на любом языке (за некоторыми исключениями), который превосходит «супероптимизированный ассемблер». Написание эффективного кода не зависит от языка и часто не зависит от лучших алгоритмов (но иногда зависит). Это оптимизация использования памяти и кэша. И это ортогонально тому, о чём пишет автор. Кроме того, LLM ужасны в оптимизации использования памяти. Слишком мало обучающего кода, который делает это хорошо, и слишком много того, который не делает.

В качестве доказательства я буквально чувствую, как веб замедляется, и уверен, что многие другие тоже это чувствуют.

ChatGPT MacOSX — единственное ПО, которое регулярно падает на моей машине, когда его потребление памяти без видимой причины разгоняется до 50 ГБ.

И это ПО создано одними из самых высокооплачиваемых инженеров на планете с полным доступом ко всем вычислительным мощностям LLM в мире.

Я пользуюсь компьютерами четыре десятилетия. Они не стали быстрее. Компьютерная система АЭС, которую мы построили в 1989 году, должна была отображать выбранные экраны за 1 секунду. Не думаю, что какие-либо приложения, которыми я пользуюсь сегодня, могут это сделать.

Для меня сравнение всегда было 3DsMax против Blender. Тот же тип ПО, те же функции, но Blender намного быстрее.

Архитектурные решения всегда были важны.

Я теперь понимаю, что большинство ПО медленное из-за причин, связанных с совместным проживанием, требующих контроля ресурсов, или просто потому, что оно безопасно изолировано от конкуренции. Например, GitHub — это первое: вы можете сами создать себе git-хостинг и CI/CD систему гораздо более высокого качества, поскольку вы, вероятно, не используете его социальные функции. Я думаю, что такие вещи, как жест Apple с пятью пальцами внутрь, — это второе. Раньше можно было сделать жест и начать печатать, но сейчас нужно дождаться рендеринга анимации и т.д., прежде чем нажатия клавиш зарегистрируются. Это ПО медленное, потому что вы не можете заменить его в MacOS.

Но всё это со временем изменится. Ад — это чужое ПО.