Rust обогнал Сишечку по скорости распаковки

Опять ты троллишь.

почему zlib на Си так плохо оптимизирован?

zlib написан так, чтобы быть совместимым со всеми платформами, существовавшими за последние 40 лет. Включая 16-битные, включая pre-C89 (K&R) компиляторы итд. Скорость там наверно старались чтоб не была совсем плохой, но приоритетным оно давно не является. В конце концов, есть куча других как реализаций deflate, так и вообще других алгоритмов сжатия, более быстрых и/или более сжимающих. Суть zlib - в сквозной совместимости со всеми подряд и в стабильном коде без лишних нововведений, а не в том чтобы с кем то соревноваться.

О, типичные растовики - заплати мне, чтобы мой софт работал у тебя

растишка … компилировался полтора часа

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

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

minus_swap(&a, &b);
if (a == INT_MAX) {
  // Some code
}

Оптимизатор может исходя из вызова функции разумно предположить что код в условии никогда не вызовется и удалить его. Даже если существующие компиляторы так не делают это корректная оптимизация, потому что для знаковых типов переполнение это UB, и оптимизатор может всегда исходить из предположения что UB никогда не происходит, а значит что значения a и b находятся в диапозоне от INT_MIN/2 до INT_MAX/2 и соотвественно условие a == INT_MAX можно считать всегда ложным.

Небольшая поправка - условие должно быть что-то вроде a == INT_MAX && b > 0, чтобы оно было всегда ложным исходя из логики что UB никогда не происходит.

Что скажут эксперты по Си

Я не эксперт, конечно, но в оп-посте логическая ошибка: из факта что конкретная реализация алгоритма на расте обогнала конкретную реализацию алгоритма на си не следует что раст обогнал си по скорости

Одно добро пошло: то zlib переписан на Rust, то Лайнус и Грег поддерживают Rust в ядре, то большущие пачки новых уязвимостей Xorg. Rustls уже есть, smithy и uutils в процессе. Красота.

Ну так раст и в 2030 будет хобби-проектом заднеприводных, на котором так и не будет написано ни одного нового полезного кому-то кроме растаманов проекта. Растаманы фундаментально не способны придумать ничего своего, могут только переписывать чужое и настырно пытаться пролезть в каждый проект со своей хобби-поделкой. :)

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

Go woke - go broke - уже давно доказано практикой. Go rust - go broke тоже станет таким же непреложным законом. Потому что rust === woke.

Вот сравнить бы с libdeflate, например…

Это какой-то позор.

Потому что rust === woke

Педеруст

о, опять школьники со школьными примерами подтянулись

А теперь факты - растаманы за бабки от гранта по подсказке сотрудника редхад Никиты Попова включили флажок в llvm. Достижение достойное ЛОР.

Ещё как можно.

А как? Если посмотреть ассемблерный код, который генерирует компилятор из си, то несложно заметить что там то же самое что на си, только на ассемблер, как можно быстрее? Оптимизациями?

включили флажок в llvm

Этот флажок безопасТный?

Спорим на штуку баксов, что через два года Rust всё ещё будет в ядре?

Что-то ты продешевил, надо сразу заряжать €95.000 :)

Тем временем, самые ярые проталкиватели раста в ядро linux видели максимум в виде виртуалки.

Оригинальная реализация zlib далеко не самая быстрая

Там с zlib-ng везде сравнение.

Тем временем, самые ярые проталкиватели раста в ядро linux видели максимум в виде виртуалки.

Самые ярые противники тоже.

Да, не бесплатно - получилось быстро на x86, но медленно на PDP-11, а у С - наоборот.

Если так, то приемлимо.

Самые ярые противники тоже.

Покажи пальцем.

Покажи пальцем.

половина лора и почти весь opennet.

половина лора

Не имеет представления, что такое раст.

почти весь opennet

Смешно. Там все безопасТники, которые linux вообще не видели.

А то что оно не собирается компилятором от июня прошлого года это так и задумано?

Ого, кто-то даже попытался в фактчекинг.

Разница в производительности может достигать аж 14%.
почему zlib на Си так плохо оптимизирован?

Эка невидаль! А у zlib-ng разница в разы. Ты что, не читал lzbench 2.0 и 2.0.1?

По ссылке из ОП сравнение как раз с zlib-ng.

По ссылке не ходил, а ТС набросил так, как набросил.

Rust в этом плане куда проще оптимизировать

Тогда за что эти ребята 95k ойро хотят? Ведь включая все изложенное выше раст должен из коробки генерить более быстрый код. А тут оказывается чот надо оптимизировать вручную

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

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

Переписали уже называется zlib-ng, именно с этой версией и оптимизированной версией из chromium (тоже переписанной) и сравнивают.

Есть, потому что софт на Rust непонятно как компилировать. Сборщик хочет качать какие-то гигабайты с васянских серверов непонятно где.

Ну.. тот же Гектор Мартин и его компания геев в юбках, которые топят за Rust, портировали этот твой лялекс на новые макбуки на армах. В плане программирования, они достаточно годные ребята. Правда, в остальном у них кукуха уехала давно и надолго.

Сборщик хочет качать какие-то гигабайты с васянских серверов непонятно где

Я понимаю, что тебе просто набросить, и к теме разработки хоть на чём ты отношения не имеешь, но если что: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

Опять ты троллишь.

Да. А ты ведёшься.

zlib написан так, чтобы быть совместимым со всеми платформами, существовавшими за последние 40 лет.

Нет. По ссылке сравнение с zlib-ng и версией zlib из Chrome/ium. Обе никогда не портировались ни на какие 16-битные платформы и не собираются ничем кроме gcc/clang/msvs (про последний не знаю).

Разница в производительности может достигать аж 14%.

Это революция! Мир никогда не будет прежним.

Тогда за что эти ребята 95k ойро хотят?

Им нравится бабло. Кто мы такие, чтобы их в этом винить?

Я понимаю, что тебе просто набросить, и к теме разработки хоть на чём ты отношения не имеешь, но если что: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

я не шучу. Я честно не понимаю, как собрать примтивнейший софт на rust, чтобы не потратить куда-то пару гигов места на диске. Как будто второй дистрибутив в виртуалку ставлю. Это всегда так будет теперь?

Сборщик хочет качать какие-то гигабайты

В данном случае удивительно мало зависимостей:

[dependencies]
arbitrary = { workspace = true, optional = true, features = ["derive"] }
quickcheck = { workspace = true, optional = true }

и то одна для тестирования чисто, но почему-то добавлена не в dev-dependencies

с васянских серверов непонятно где

Это ты с golang перепутал, у rust же централизованная репа по умолчанию.

Я честно не понимаю, как собрать примтивнейший софт на rust, чтобы не потратить куда-то пару гигов места на диске. Как будто второй дистрибутив в виртуалку ставлю. Это всегда так будет теперь?

Так претензия к загрузке «откуда-то» или к необходимости иметь сборочные зависимости? Зависимости тебе придётся иметь в любом случае. И да, как и с более старыми языками, их ты можешь поставить из репозитория своего дистрибутива. По крайней мере, в Debian такие правила, и там софт на Rust и Go собирают строго так. Разумность такого подхода дискуссионна, но свои плюсы в этом есть.

как собрать примтивнейший софт на rust

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

Раст сделан и спроектирован по образу и подобию бога, ой, жабаскрипта.

интересно есть zlib на C переписать с нуля сейчас

Я когда-то написал о существовании https://www.hanshq.net/zip.html.

Марк Адлер добавил это великолепие в «Related External Links» на сайте https://zlib.net.

В связи с этим поистине знаковым событием в истории не только RUST, но и всей индустрии, поздравляем не только программистов на RUST, но и на всех остальных (неправильных) языках программирования. Теперь вы еще на шаг ближе к тому чтобы вместо вашего любимого ЯП писать на правильном Расте. Осталось немного, всего 99% кода еще не переписано на Раст. Но вектор мирового программирования ясно указывает путь. Путь на безопасную разработку в небезопасном режиме, верным путем идем товарищи. Скоро, уже совсем скоро, каждая ЭВМ отринет ложные витамины и окрасится истинными красно-коричневыми цветами Ржаволюции! Осталось еще немного потерпеть. Возрадуйтесь товарищи! Учение ржавы всесильно, потому что оно верно!

интересно есть zlib на C переписать с нуля сейчас

Переписали уже называется zlib-ng

4.2, она не написана с нуля, это форк.

Заголовки уже более чем 20-летней давности

http://www.codenet.ru/webmast/java/javavscpp.html

Только тепер Хруст!!1

Обогнал кого-то, а пацаны, что пишут на Сишке даже и не знали, что все… приехали)

Но тогда они просто мошенники и мы обязаны их осудить

Но тогда они просто мошенники

Вообще ни разу. Чуваки выкатили демку и предлагают им заплатить за продолжение. Не вижу здесь никакого мошенничества. Они никого не обманывают.

Rust обогнал Сишечку по скорости распаковки

Бред.

Не знаю, как Rust, а C - компилятор, причём управлять компиляцией можно из исходного когда. Следовательно быстрее быть не может быть ничего, может быть только так же. С погрешностью на качество компиляции, ну и алгоритма конечно. Ну и ассемблер, конечно, но тут ты просто будешь с копиляторм в эффективности соревноваться, может победишь, может нет. Про другие языки можно про удобство говорить, про скорость написания, пресловутую безопасность, контроль ошибок, отладку и т.п., но никак не про «быстрее».

Если посмотреть ассемблерный код, который генерирует компилятор из си, то несложно заметить что там то же самое что на си

Чо? Сишные компиляторы такую лютую дичь творят с кодом, что «то же самое что на си» будет только для очень простых примеров.

Впрочем, компиляторы других языков зачастую творят ещё большую дичь. Я тут видел сравнение программирования на хачкелле с насильственной обфускацией бинарников, потому что по бинарнику вообще хер поймёшь что было в исходниках. GHC делает чудовищный инлайнинг всего подряд во всё остальное, плюс преобразовывает код в CPS. То есть, вызовов функций в сишном стиле в бинарниках из хаскелла почти что и нет.

Там есть почитать, то ситуация такая:

• Есть кроссплатформенный код на С, который форк кода столетней давности, у которого не было цели быть быстрым
• Код собран без флагов на оптимизацию по скорости
• Чуваки написали код на расте под один единственный процессор с сильной заточкой на доступные ему simd инструкции.
• Кроме совсем базового функционала там ничего нет
• Дай 9 лямов рублей, а то не будем продолжать
• «Раст уделал Си!!»