Комментарии 19
значит нужно 4 недели и 40 штук баксов)))))
Компилятор С это задача на... Ну может 10 тысяч строк кода. И при том задача очень простая, решённая в опенсорсе тысячи раз, с чёткой спецификацией, бесчисленным количеством тестов...
И при всём этом, всё равно ничего толкового не вышло. А теперь представьте задачу, для которой нет готового решения. Короче, реклама ЫЫ уже достала всех
Компилятор генерирует неправильные релокации для структур __jump_table и __ksymtab, поэтому итоговый бинарник vmlinux собрать не удалось. Заявление Anthropic о сборке ядра формально верно — но только для этапа компиляции, не для получения рабочего образа.
Формально Антропик солгал.
Подозреваю они просто устали от бесплодных попыток заставить агентов написать работающий компилятор и решили, что и так сойдёт.
Заявление Anthropic о сборке ядра формально верно — но только для этапа компиляции, не для получения рабочего образа.
Хм, а давайте посмотрим, что они сами заявляют:
The 100,000-line compiler can build a bootable Linux 6.9 on x86, ARM, and RISC-V.
Кажется, что-то хоть как-то рабочее все-таки должно было получиться.
Как демонстрация возможностей Claude результат впечатляет: ИИ написал 100 тысяч строк компилятора, который корректно разбирает реальный C-код.
У нас был "браузер" от Cursor на 3 миллиона строк кода (по итогу - слопобаза), недавно проскакивал VibeSQL (Вроде порядка 400к строк кода, но, судя по полуживому и люто забагованному сайту, есть сомнения, что в этой кодовой базе есть много адекватного). Теперь вот нам опять кидают количество строк кода с явным намеком "Смотрите, какой сложный проект".
На деле же, большинство оценок, которые я смог найти, говорят о том, что эта задача требует примерно 10-15 тысяч строк кода. В общем говоря, на практике это цифра не особо что-то показывает.
Но до практического применения CCC далеко — 40 лет оптимизаций GCC пока не заменить за две недели и $20 000 на API.
Ну, давайте будем честны: самая первая вещь, которая отделяет CCC от практического применения, это вагон багов, а не 40 лет оптимизаций. И этот же вагон багов в целом отделяет CCC от "компилятор С, который ответственно разрабатывался в течение 2-3 месяцев".
TCC (Tiny C Compiler) - ~50k строк. Собирал ядро Linux (2.4, частично 2.6)
Сейчас надо ещё потратиться на GCC-специфичные расширения (
__attribute__,
__builtin_*, inline asm, statement expressions), которых в ядре сотни. Итого, 100К нормальная величина
Ядро годами тестировалось только на GCC, и де-факто зависит от:
конкретного поведения GCC при UB (порядок вычислений, aliasing)
недокументированных деталей inline asm constraints
специфики как GCC раскладывает структуры с bitfields
поведения __builtin_constant_p в контекстах где стандарт молчит
Поэтому, тут багофич больше чем документированных фич
TCC (Tiny C Compiler) - ~50k строк.
Такое сравнение, кажется, некорректно. Могу ошибаться, но:
- TCC включает в себя не только непосредственно компилятор.
- TCC имеет фичи, которые не являются необходимыми для сборки ядра Linux
- Anthropic ставили перед собой задачу сделать компилятор, который в принципе имел бы возможность хоть как-нибудь скомпилировать ядро Linux, без оглядки на скорость работы, баги и прочее. Потому часть важного функционала не реализована/реализована частично/реализована некорректно. Внятная же реализация этого, вероятнее всего, раздула бы код ещё сильнее.
Сейчас надо ещё потратиться на GCC-специфичные расширения.
Потратиться-то надо, но не особо ясно, сколько это добавит строк кода, если учесть, что задача у нас в таком случае будет "реализовать расширения ровно настолько, чтобы компилятор мог собрать Linux, без оглядки на всё остальное" (я сильно сомневаюсь, что у компилятора от Anthropic много GCC-специфичных расширений, которых можно назвать "корректно реализованными" со сколь-нибудь адекватной точки зрения).
И кого они пытались впечатлить?
Пока интрига держится - некоторые думают что лучше не станет (и уже фактически уперлось в потолок возможностей), другие же прогнозируют что через 3-5 лет произойдет качественное улучшение.
Как по-мне, так это хороший бенч, вместо глупых циферок в стиле 87.5% vs 90.3%. А также полезно для истории, года через 2-3 будет очень любопытно сравнить как новые модели будут решать ту же задачу.
У антропика пиар служба очень круто работает. Они скоро на IPO хотят выйти. Но в целом тренд правильный. Сейчас пока вышел блин комом, но думаю в ближайшем будущем все будет как надо. Мне в начале мистраль и антропик сильно нравились. Щас по итогу юзать стал и продолжил только ChatGPT. Но в поиске стал юзать google ai. Хотя иногда прям в запросе стал ChatGPT просить проверь информацию в интернете. Вобщем всетаки ChatGPT пока лучше всех. Не знаю чем их борьба кончится. Помню альтависту и рамблер. И где они сейчас?)
Да где же блин комом? LLM сделала задачу которую 90% современных разработчиков в принципе не смогут осилить даже за 5 лет. Получилось не идеально, но оно работает после первой итерации. Перекладывать json`чики больше не считается элитной разработкой имхо...
Мне казалось, что перекладывателей json-чиков считали(или считают) элитой только те же перекладыватели и то, только по зарплатному признаку.
А так, блин действительно комом. И действительно маловероятно, что за 5 лет рядовой разработчик напишет 100к строк частично работающего кода. Потому что не нужно столько строк кода для такой задачи.
Это всё очередная демонстрация того, что LLM не могут ни в какую инженерию и проектирование, а хороши лишь для решения узких, заранее хорошо декомпозированных задач
Как по мне очень странная статья, использовать opus и т.д. Нужно так-же уметь, в зависимости от промтов, как поставлена задача и вообще не очень ясно какую именно модель использовал, чем cli, ide? Все это выглядит как если бы дорогую коллекционную модель дали 5 летнему ребенку, который бы в ответ сказал, да крутая модель, но это не настоящая машина

Собранный Opus 4.6 компилятор провалился в независимом бенчмарке