Комментарии 36
иногда (постоянно) складывается впечатление, что rust-фанатам важно всё сделать на rust.
Зачем? Чтобы на rust.
Самое главное, чтобы добиться производительности они используют unsafe Rust, и все равно кричат о безопасности, хотя в том же rav1d полно unsafe вставок и вызовов unsafe функций.
Там философия заключается в том, что ты осознанно пишешь небезопасный код, явно сообщая об этом. Меньше шансов выстрелить себе в ногу, если пистолет на предохранителе.
Чем это принципиально отличается от того что "ты осознанно пишешь небезопасный код на СИ, явно сообщая об этом (файлы явно имеют расширение .c)" ?
В расте весь код безопасен по умолчанию, в си весь код по умолчанию небезопасен. То есть в си ты сначала осознанно пишешь небезопасный код, явно сообщая об этом, а потом пишешь настолько же небезопасный код, но уже неосознанно.
Тем, что половина того Си кода примерно никак не валидируется статически без тонны внешних инструментов, хотя теоретически могла бы. Область небезопасного кода в среднем получается больше. Отдельная история с макросами.
что rust-фанатам важно всё сделать на rust.
Это очень странный тейк. В го например написали свою собственную имплементацию протокола SSH, а не использовали какой-нибудь openssh вместо этого. Получается гошники тоже фанаты? Зачем-то взяли и переписали всё, включая криптографию и сервер.
Отдельно стоит упомянуть, что Xiph.Org изначально писала энкодер на Rust например, так что ещё не ясно кто кого переписал.
Да, если есть хорошая отлаженная бибиотека которую можно заюзать без танцев с бубнами - это фанатизм на мой взгляд. Какая была цель написания этой библиотеки в итоге?
заюзать без танцев с бубнами
вот тут то и зарыта собака
Какая была цель написания этой библиотеки в итоге?
Иметь нативную имплементацию на некотором целевом языке. Минус зависимости - компилятор С/С++, make/cmake/etc. Меньше проблем в случае нахождения багов/уязвимостей - своё фиксить проще, чем дождаться пока чужие примут PR и раскатают по миру. Можно конечно пойти по пути Zig и иметь ещё и компилятор С, но это кажется это ещё больший оверкилл чем переписать библиотеку. Ну и надо иметь программиста не только на этом языке, но и на языке зависимости.
Не страдать от проблем со "странным" API связанного с нюансами C и FFI и сделать достаточно эргономичный интерфейс не имея проблем совместимости, которые приходится учитывать в сторонней библиотеке. Да и непосредтсвенно ABI для FFI тоже имеет свою чёрную магию, для которой нужны продвинутые программисты.
Избежать проблемы выбора библиотек - если погуглить какие-нибудь парсеры json, то окажется, что их там тоже 20+ вариантов. Какой из них лучше использовать и сколько он всякого добавит при этом в сборочную систему?
Потенциально ещё иметь возможность сделать оптимизации, которые опять же могли быть не сделаны из-за поддержки легаси или неочевидного API. Такие штуки иногда случались при переписывании на Rust.
Поэтому в среднем если что-то улучшает экосистему языка, то иметь нативную имплементацию несколько выгоднее, нежели заморачиваться с обёртками над существующими библиотеками. Хотя впрочем никто не запрещает этим заниматься и обычно существует немало подобных обёрток, но в виде внешних библиотек.
Касательно кодеков - полная мотивация иметь столько различных имплементаций не до конца ясна, даже в пределах одного языка. Вангую это как иметь несколько независимых компиляторов по типу gcc vs clang vs msvc - некоторая конкуренция приводит к улучшению ниши в среднем.
Отдельно касательно имплементации в Go - Google несколько подвержен NIH-синдрому, поэтому это тоже вероятно отдельный драйвер переписывания, но это уже на уровне догадок.
Всё верно и по делу! Без нативной имплементации технологий - обслуживание кодовой базы, сборка и дистрибуция превращается в сущий кошмар. Кучи продуктов просто не было бы.
До сих пор если в проекте на GO есть какие-то С вставки приходится тратить кучу времени на то, чтобы разобраться с кросс-компиляцией и не всегда это даже получается, например если дело касается GUI приложений.
Ну и в конечном итоге если кто-то готов заплатить 20к за оптимизацию библиотеки, ну хорошо же)
Нет. Только решая реальные задачи, можно выявить слабые места. А переписывать уже существующее удобно. И логика уже есть и можно сравнить результат.
А там нет какой-то простой обертки над C библиотекой? :) А то я готов . Правда возможно и в этом случае производительность пострадает
Наш декодер rav1d на основе Rust в настоящее время примерно на 5% медленнее декодера dav1d на основе C
Ребята как раз ищут волшебника, который попадет в игольное ушко, шириной в 5% производительности.
Если эта проблема возникает в архитектуре компилятора, то решать ее нужно там, а не в конкретном проекте.
В требованиях как раз и сказано, если надо,улучшите компилятор rust:)
Ааа упустил про 5%, неужели это реально им так важно?
.
Скорее всего, проблему производительности можно будет решить за счёт увеличенного потребления памяти, заранее выделяя большие участки под вычисления. Так что ждём второго конкурса - теперь уже на снижение потребления памяти, относительно решения на C.
Практика показывает что иногда выходит даже быстрее С, но часто это достигается ценой обертывания все в unsafe и применения решений специфичных для конкретной архитектуры. Такой код довольно уродлив и плохо читаем. Почему нельзя было решить дело с помощью extern "C" там оверхед чаще всего очень маленький?
А не может быть так, что в С версии отсутствуют некоторые проверки требуемые компилятором раста? И поэтому скорость отличается.
Интересно, а они же сравнивали свою сборку с сишной, которая собрана той же версией LLVM?
5%? Ну пишите ассемблерные вставки на критических участках. Всё имеет свою цену
Бгг, "Библиотека написана на расте с небольшими ассемблерными вставками" :)
Наверное счётчик всё же строки кода считает, а rust пожалуй немного более выразительней чем асм в пересчёте на эти самые строки 😊
Собсвенно с большой вероятностью критические блоки перекрывют по строкам обычный Rust код, т.к. он asm вербозный и наверняка есть имплементации под разные архитектуры (x86, arm и тп). А код на Си - байндинги для других языков.
Тогда они неправильно написали условия конкурса :)
Хотя если написать что ищут asm разработчиков оптимизировать код - никто не откликнулся бы, они все уже как мамонты
о нет, не стоит наверно, опять появятся переписывальщики, чтобы показать на тестах потом как быстро )
Ну перепишут они его на Rust, и кто им будет пользоваться? Кому вообще нужен программный декодер AV1 в 2025?
Всем тем, кто сидит на железе, не умеющем аппаратно ускорять AV1.
Например, у NVIDIA это карты старее RTX 3000, а у AMD - старее 6000 серии (и то не все карты в 6000 серии умеют в AV1). Учитывая, что большая часть пользователей использует встроенную графику Intel, там в пролёте вообще все, кроме обладателей встроенной графики последних поколений.
Ну тут явно все ради именно rust. Соседняя команда как-то делала проект за деньги одного производителя GPU написания декодера vp9(не завезли апаратный еще к тому времени). И декодер - это скорость, любой декодер на Cpu - это больше интринсики sse либо neon, нежели чистый С. Раньше это были сплошные асемблерные вставки. Другое дело это референсный декодер, там главное это простота кода, но референсный декодер никогда не был быстрым. Если речь о простоте, то может rust оправдан(для писателей на rust) Но честно говоря мой прогноз что AI раньше чем rust заменит C, и rust - это уже тупиковая ветвь развития, хотя и забавная)
Если ваша мисс-мира такая красивая, вам не нужно доплачивать 20000$ за то, чтобы хоть кто-то взял её замуж.
Проект rav1d (декодер AV1 на Rust) ищет разработчиков, кто за $20 тыс. сделает это решение таким же быстрым, как на C