![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Я всегда говорил - пусть искусственный интеллект напишет компилятор, тогда и поговорим. И вот, действительно, сотрудник Антропика написал с помощью Клод Опуса компилятор С. Антропик Клод, как я слышал, наиболее подходящий спамогенератор для программирования. Компилятор имеется в виду именно С (не C++) и неоптимизирующий. Написан на расте. Он почти работает, только генерирует код в сотни раз медленнее настоящего неоптимизированного кода (gcc -O0).
Тут надо сказать, что я сам в устройстве компиляторов ничего не понимаю, поэтому мне во всей этой истории показалось самым интересным, что неоптимизирующий компилятор С это настолько сложная вещь.
Так или иначе, вот исходная статья: https://www.anthropic.com/engineering/building-c-compiler
И вот интересная рецензия: https://harshanu.space/en/tech/ccc-vs-gcc/
Методологически, это не совсем такой искусственный интеллект, как я имел в виду. Я хотел, чтобы входными данными были все тексты на С и результаты их компиляции, а функциональность компилятора была бы сосредоточена в коэффициентах модели. Здесь подход другой: возьмём составленные людьми юнит-тесты настоящего компилятора, и методами искусственного интеллекта подберём такой код на расте, который проходит наибольшее их количество. Оказалось, что это возможно, и в результате получается почти что работающий компилятор C.
Насколько я понял, автор посчитал дальнейшее развитие такого компилятора бесперспективным:
Claude will work autonomously to solve whatever problem I give it. So it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem. Improving the testing harness required finding high-quality compiler test suites, writing verifiers and build scripts for open-source software packages, and watching for mistakes Claude was making, then designing new tests as I identified those failure modes.
For example, near the end of the project, Claude started to frequently break existing functionality each time it implemented a new feature. To address this, I built a continuous integration pipeline and implemented stricter enforcement that allowed Claude to better test its work so that new commits can’t break existing code.
[...]
The resulting compiler has nearly reached the limits of Opus’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.
ОК!
Тут надо сказать, что я сам в устройстве компиляторов ничего не понимаю, поэтому мне во всей этой истории показалось самым интересным, что неоптимизирующий компилятор С это настолько сложная вещь.
Так или иначе, вот исходная статья: https://www.anthropic.com/engineering/building-c-compiler
И вот интересная рецензия: https://harshanu.space/en/tech/ccc-vs-gcc/
Методологически, это не совсем такой искусственный интеллект, как я имел в виду. Я хотел, чтобы входными данными были все тексты на С и результаты их компиляции, а функциональность компилятора была бы сосредоточена в коэффициентах модели. Здесь подход другой: возьмём составленные людьми юнит-тесты настоящего компилятора, и методами искусственного интеллекта подберём такой код на расте, который проходит наибольшее их количество. Оказалось, что это возможно, и в результате получается почти что работающий компилятор C.
Насколько я понял, автор посчитал дальнейшее развитие такого компилятора бесперспективным:
For example, near the end of the project, Claude started to frequently break existing functionality each time it implemented a new feature. To address this, I built a continuous integration pipeline and implemented stricter enforcement that allowed Claude to better test its work so that new commits can’t break existing code.
[...]
The resulting compiler has nearly reached the limits of Opus’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.
ОК!