Обновить

Комментарии 19

значит нужно 4 недели и 40 штук баксов)))))

в социалку в молтен закинуть рацуху , другие "агенты" справятся , будет колоборация и вайб кодинг

Компилятор С это задача на... Ну может 10 тысяч строк кода. И при том задача очень простая, решённая в опенсорсе тысячи раз, с чёткой спецификацией, бесчисленным количеством тестов...

И при всём этом, всё равно ничего толкового не вышло. А теперь представьте задачу, для которой нет готового решения. Короче, реклама ЫЫ уже достала всех

Я полностью согласен с посылом, но для корректности стоит всё-таки добавить, что эти ИИ не имели (в процессе работы по крайней мере) доступа к опенсорсу. Т.е. обгадились вполне себе самостоятельно.

Я не верю, что Antropic не обучала свой Claude на миллиардах строк опен-сорса.

Компилятор генерирует неправильные релокации для структур __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 летнему ребенку, который бы в ответ сказал, да крутая модель, но это не настоящая машина

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости