LINUX.ORG.RU

Rust всемогущий: ищу истории успеха

 ,


1

6

Всем привет!

Помнится тут на ЛОРе мелькала библиотечка про SVG, что на расте уделывала имеющиеся аналоги. Интересно, есть ли ещё подобные случаи – из тех что вам попадались на глаза или обсуждались здесь ранее. Если с реальными бенчмарками и цифрами – то вообще отлично!

Да, тут только вышел из спячки, форум не читал особо последние лет 5, в гугле тоже забанили и в местном поиске особо ничего не нашёл

★★★★★

Ответ на: комментарий от einhander

Пример хороший, но немного не то – сравнить не с чем(?)

Хороший гипотетический пример: вот LAME-кодек на сишке отработал за 0м5с, а LAME-кодек на расте за целых 0м4с

yoghurt ★★★★★
() автор топика

Переписывается в основном что-то простое. Там не получится сравнить производительность. А то, что новое пишется, прямых сишных аналогов не имеет. Так что сложно будет найти объекты для сравнения.

CrX ★★★
()

если уж говорить про переписывание, то стоит уопмянуть тот факт, что разумное и просчитанное переписывание обычно улучшает код. прост потому что в архитектуре нового кода учитываются все ошибки, набитые на старом.
так что обычно да. переписывание всегда получается лучше чем старое.
и это даже без привязки к языку :)

pfg ★★★★★
()
Ответ на: комментарий от pfg

Не знаю откуда вы все берете «переписывание», в ОП я специально не использовал это слово, а применил «аналог».

Реализация внешнего контракта (будь то - визуализация векторной графики, алгоритма кодирования, да того же разбора JSON-а) с условного чистого листа без заглядывания в легаси решения (ну ладно, краем глаза-то можно) это всё же не «переписывание», наверное

yoghurt ★★★★★
() автор топика
Ответ на: комментарий от pfg

ну и да, если уж развивать эту тему (что будет оффтопиком), порой старые велосипеды настолько ужасно зарастают мхом и техническим долгом, что разбираться там черт ногу сломит, проще взять спеку и пойти уже по ней.

yoghurt ★★★★★
() автор топика
Последнее исправление: yoghurt (всего исправлений: 1)

По-моему парадигма Rust это «за +10% оверхеда получите +50% продуктивности разработчика в сравнении с C или C++». Странно спрашивать про бенчмарки.

На Rust не напишешь код как в ядре, когда ради минимизации cache misses в одной структуре одновременно упакованы данные, парочка intrusive списков, intrusive rbtree индекс, атомики на разных кеш линиях, и всё это ещё синхронизировано под rcu.

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

snizovtsev ★★★★★
()
Последнее исправление: snizovtsev (всего исправлений: 1)

Было, но какими проектами она применялась осталось неизвестным. Потом librsvg автор переписал на rust. Это больше на историю успеха похоже. Не знаю как по скорости работы, но скорость сборки пострадала значительно.

grem ★★★★★
()

Согласен с предыдущим оратором. Почему сравнение по скорости выполнения, а не по времени разработки (с уменьшенным временем отладки и багфиксинга)?

Всё что в Расте сделали - добавили к параметрам функций возможность описывать кто и как владеет данными с той и с другой стороны вызова.

Это конечно полезно для понятности и определённости, надёжности и т.д., но странно от этого ждать каких-то ускорений.

Shushundr ★★★
()
Ответ на: комментарий от einhander

Оно пока для пародийрецензий. Итого: историй успеха нет. Есть хайп-цыкол, который еще не прошел проверку стандартизацией и метрологией. Стандарт языка есть? Стандарта нет. Есть много вишфул манямирка про «вот-вот все перепишут». Угу, держите карман шырее.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от Shushundr

Почему сравнение по скорости выполнения, а не по времени разработки (с уменьшенным временем отладки и багфиксинга)?

Замечание валидное, но вроде ОП-пост ему и не противоречит. Сложностью тоже надо управлять, и если один растаман обпишет трёх сишников, почему бы и нет, я бы и на такое посмотрел

yoghurt ★★★★★
() автор топика

https://github.com/ixy-languages/ixy-languages/blob/master/Rust-vs-C-performance.md

ну он ожидаемо отсасывает с заглотом у C по скорости, а все эти говнолибы на расте - не более чем пет-проекты зумеров. Если раньше на работу брали стоит тебе соврать, что что-то умеешь, то теперь нужно на гитхабе проекты со звездами иметь

uwuwuu
()
Ответ на: комментарий от uwuwuu

чисто визуально код на расте ужасен, нечитаем, а написание его сложно из-за нюансиков. переписывание чего-то не имеет смысла, а вот написание нового… ну если зумеры не хотят сишку учить, то пусть на чем угодно пишут

uwuwuu
()
Ответ на: комментарий от Shushundr

Всё что в Расте сделали - добавили к параметрам функций возможность описывать кто и как владеет данными с той и с другой стороны вызова.

странно от этого ждать каких-то ускорений.

Кхм, какой интересный редукционизм. Попробую парировать так: теоретически, можно в С вообще ничего не трогать, только restrict поменять на norestrict, чтоб по умолчанию был, и какая-нибудь хрень уже ускорится.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Можно. Но это не имеет значения. Имеет значение то, что в Rust возможность описывать добавили, но вот в LLVM не добавили.

Вернее, в LLVM этот функционал был задолго до Rust, но он сломан, поэтому Rust им не пользуется. За ~8 лет существования Rust в современном виде никаких попыток починить предпринято не было.

И даже более того, аннотации __restrict__ и их аналоги имеют какой-то смысл исключительно в контекстах, где компилятору недоступно определение функции.

Siborgium ★★★★★
()
Ответ на: комментарий от uwuwuu

В тексте readme какие-то кулстори про передачу по значению в Rust и по указателю в С. Что мешает передавать в С по значению – неясно.

Но все еще смешнее. Если немного почитать код, то там у Rust случились prefetch’и и SIMD, которых в С нет.

И даже так получился слив. Бывает.

Siborgium ★★★★★
()
Последнее исправление: Siborgium (всего исправлений: 2)
Ответ на: комментарий от Siborgium

Rust enforces bounds checks while the C code contains no bounds checks (arguably idiomatic style for C)

что он несет вообще?))

Wow, looks like we should really be asking how Rust manages to be so fast! The CPU executes 65% more instructions per forwarded packet with the Rust driver compared to C. But it manages to do so with only 6% (11%) more cycles per packet for batch size 32 (batch size 8)

он типа думает, что процессор исполняет для раста какие-то особые инструкции, которые не получишь в коде на сишке?))

Lrrr ★★★★★
()
Последнее исправление: Lrrr (всего исправлений: 1)

Вот история успеха https://www.opennet.ru/opennews/art.shtml?num=58775

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

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

Правда там не так всё прямо, генерируемый код кривой получается, но финальная суть остаётся.

=)

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

нашел тут список историй успеха: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

Cargo did not perform SSH host key verification when cloning indexes and dependencies via SSH

It was discovered that Cargo did not limit the amount of data extracted from compressed archives. An attacker could upload to an alternate registry a specially crafted package that extracts way more data than its size (also known as a «zip bomb»)

современный, инновационный, лучший в своем классе менеджер пакетов

We recommend users of alternate registries to exercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities

это на фоне того, что оно ssh-ключи не проверяет

Cap’n Proto’s Rust implementation … are vulnerable to out-of-bounds read due to logic error handling list-of-list

там вроде где-то написали, что «rust enforces bounds checks»?

totp-rs is a Rust library that permits the creation of 2FA authentification tokens per time-based one-time password (TOTP). Prior to version 1.1.0, token comparison was not constant time

безопасная генерация кодов для 2FA

An issue was discovered in the lru crate before 0.7.1 for Rust. The iterators have a use-after-free

безопасная работа с памятью в лефтпаде

и т.д. и т.п.

Lrrr ★★★★★
()
Последнее исправление: Lrrr (всего исправлений: 1)
Ответ на: комментарий от yoghurt

Хороший гипотетический пример: вот LAME-кодек на сишке отработал за 0м5с, а LAME-кодек на расте за целых 0м4с

Ну в интернетах говорят, что растовый ripgrep прилично быстрее сишного grep’а, например.

Но ты явно хочешь странного, это всё от алгоритма зависит. Оптимизатор то у языков одинаковый - llvm. Да, на расте хорошие алгоритмы писать и сопровождать проще, но это про цену разработки, а не про скорость работы софта. То, что на расте она меньше, по-моему и так очевидно. Цена разработки почти на всём меньше, чем на сишке.

Ivan_qrt ★★★★★
()

В JS мире раст значительно улучшает состояние тулинга, особенно производительность, часто в 100+ раз. Примеры: webpack -> turbopack, babel -> swc, eslint/jest -> тулинг deno. Также ядро prisma написано на rust.

Rust крайне хорош для js тулинга т.к. его легко в wasm собирать и постить в npm, у него уже есть набор библиотек для работы с js/ts и сам язык значительно приятней чем C++/С для таких целей.

WSL_user
()
Ответ на: комментарий от yoghurt

Хороший гипотетический пример: вот LAME-кодек на сишке отработал за 0м5с, а LAME-кодек на расте за целых 0м4с

Мне кажется, что как раз ваш пример плохой, ну 0м4с, с большой вероятностью так же можно соптимизировать на сишке. Что куда важнее для оценки, особенно при примерно той же производительности генерируемого кода, так это производительность разработчика, стоимость поддержки, защита от ошибок и т.д. Кажется, что Rust именно сюда и целит.

satanic-mechanic
()

в русте нет наследования, нет классов в общепринятом виде, и ООП на русте есть беспрецедентный ононизм, примерно как программировать в ооп стиле на чистом си.

осмелюсь предположить, что как только наконец появится стандарт руста, у некоторых особоретивых рустовиков появится желание сконструировать руст++, и сделать наконец все ооп там.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)