Ага

Feb. 10th, 2026 06:10 am
birdwatcher: (Default)
[personal profile] birdwatcher
Я всегда говорил - пусть искусственный интеллект напишет компилятор, тогда и поговорим. И вот, действительно, сотрудник Антропика написал с помощью Клод Опуса компилятор С. Антропик Клод, как я слышал, наиболее подходящий спамогенератор для программирования. Компилятор имеется в виду именно С (не 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.

ОК!

Date: 2026-02-10 02:27 pm (UTC)
vit_r: default (Default)
From: [personal profile] vit_r
Почти работающий софт -- это то, что стартаперы очень активно продают инвесторам. Причём, бочка бездонная. По крайней мере, до того момента как инвесторы понимают, что от "почти работающего" до "работающего" дистанция непреодолима.

Короче, вижу хорошей рынок продажи прототипов.

А с компилятором проблема не столько в оптимизации, сколько в обработке ошибок. Кто-нибудь не там скобку поставит и -- привет -- бесконечный цикл компиляции.

Date: 2026-02-10 06:03 pm (UTC)
cali4nickation: (Default)
From: [personal profile] cali4nickation
Я был уверен что в опен-сорсе достаточно компиляторов С чтобы LLM имели много примеров в своем training set.