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

Троллинг знатный.

Есть ли смысл теперь вообще писать новый софт на Си...

Тебе — нет.

мне это напомнило пиар systemd, который якобы добился супер-скорости https://www.youtube.com/watch?v=4NXMmHYNYfA
кстати, на russianfedora.ru о каком-то казино теперь на главной

а судьба zlib-rs скорее всего будет как у растового «убийцы» grep https://github.com/BurntSushi/ripgrep
тут кто-то уже выкинул grep в пользу ripgrep?

В статье не указан каким компилятором собирался тот и другой проект. По идее Rust - это clang , а си это либо gnu, либо clang. Clang и GNU по разном оптимизруют код(тут тогда вопросы больше к сравнению комплияторов). Также в случае если один и другой проект собирались на clang, т.е. к llvm-у в промежуточном счете, а это уже может означать что код rust-а действительно лучше написан , либо лучше оптимизируется clang-ом.

тут кто-то уже выкинул grep

Давно, но в пользу ugrep 7.1 и 7.1.1.

тут кто-то уже выкинул grep в пользу ripgrep?

Давно уже.

а теперь по сравнинию с этими:

https://github.com/cloudflare/zlib

https://github.com/Dead2/zlib-ng

Херовый ассемблер медленнее много чего

По идее Rust - это clang , а си это либо gnu, либо clang.

Rust – это llvm.

тут кто-то уже выкинул grep в пользу ripgrep?

Это разные тулзы, но в общем-то да. grep для скриптов и переносимости, ripgrep для «найти что-то быстро когда нет git grep».

Ну тут всё сходу ясно же, чем проще, тем лучше

Да, как и find в пользу fd

да точно, имел в виду ето

тут кто-то уже выкинул grep в пользу ripgrep?

А ты быстрый!

а судьба zlib-rs скорее всего будет как у растового «убийцы» grep

А что не так с rg? Репозиторий по ссылке живой.

тут кто-то уже выкинул grep в пользу ripgrep?

Да вроде многие.

Нет, в скриптах, где важна совместимость с любым утюгом, я, конечно, до сих пор юзаю grep, причём без гнутых фич, только POSIX. Но для интерактивного использования и для себя любимого — конечно. Не все выкинули grep именно в пользу rg, конечно — есть и другие альтернативы. Но всё же, мне кажется, давно уже все юзают кто rg, кто ag, кто ещё какое-нибудь ugrep, а не тормозной grep. fd вместо find туда же.

В статье не указан каким компилятором собирался тот и другой проект.

А они и не собирали zlib-ng, они системный использовали через растовую нашлёпку.

это уже может означать что код rust-а действительно лучше написан , либо лучше оптимизируется clang-ом.

Там копия кода из zlib-ng в упрощённом до предела виде под unsafe лишь бы распаковывало-запаковывало тестовый архив. Причём код на расте из растовой бенчмаркилки вызывается напрямую, а не загрузкой динамической библиотеки с сишным интерфейсом через прослойку на расте как с zlib-ng.

Какая разница чем собиралось, и там и там, все критичные места вручную оптимизированы с использованием simd инструкций.
Если верить приведенным результатам тестов, то растоёбам это удалось чуть лучше, но к самому расту отношения не имеет.

Как это возможно-то

Просто же: близкий к железу -> пердольный

в чём минус

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

Ну.., честно говоря, я только очень простые примеры и смотрел :)

Да и вообще, я почитал дальше тред и ты там ответил на эту претензию, и я переубедился, так что претензия снимается)

в чём минус

1. Это не минус, а обстоятельство которое надо учитывать.

2. По факту все опережение в районе стат-погрешности если брать zlib implementation used in the chromium project.

Очередная дутая сенсация, как есть.

Библиотеки на rust можно использовать из любого языка как C-библиотеки? Или есть подводные камни?

Библиотеки на rust можно использовать из любого языка как C-библиотеки? Или есть подводные камни?

Да, можно. Никаких камней быть не должно.

Библиотеки на rust можно использовать из любого языка как C-библиотеки?

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

Или есть подводные камни?

Как минимум может быть оверхэд из-за препобразований растовый структур данных в сишные и обратно.

Как минимум может быть оверхэд из-за препобразований растовый структур данных в сишные и обратно.

Он в любом случае будет в рамках преобразования языковых структур.

Вы опять выходите на связь? Думали сольетесь, помолчите денёк-другой и обезьяна отстанет? Это так не работает. Я все ещё жду ответа на два вопроса. Без них ваши суждения по любому вопросу касательно rust автоматически умножаются на ноль.

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

У ОП такой наброс, что ссылка не имеет смысла. Технически кстати это провокация flame, но почему-то модераторы решили не удалять

У него, например, в std есть SIMD. А у «близкого к железу» С – нет.

Завезли в C++26: https://en.cppreference.com/w/cpp/numeric/simd.

Вы разочаровываете обезьяна. Судя по ответам - ни одного С синьора (и тем более Rust) на форуме нет, одни джуны с вкраплениями мидлов. Видимо, это и есть уровень ЛОРа.

Никто не попытался прочитать и понять как это тестировалось. Расту накидали SIMD инструкций под разные процы и все что он делал - определял тип проца и использовал оптимальные SIMD инструкции под него сравнивая с базовой реализацией zlib на С.

Ни о каком «rust обогнал C» речи тут не идёт. Это как прострелить олимпийскому бегуну колени перед соревнованием с ним на беговой дорожке.

Вообще, игры с ускорением С версии zlib с помощью SIMD прошли 8 лет назад, просто джунам об этом не рассказали, а растрфанбои решили этим воспользоваться.

Если посмотреть на процент ускорения которое даёт SIMD на С (по ссылке выше), то там плюс минус те же цифры что дал тот же SIMD на расте.

Для тех кто с первого раза не понял, растрфанбои взяли эксперименты 8летней давности C vs C+SIMD, заменили их на C vs Rust+SIMD, получили тот же результат и выдали это за победу Rust.

Гоните растофанбоев ссаными тряпками, насмехайтесь над ними. А раст как язык вполне норм для определённых ниш. (насыпал прикормки)

Да, но это не C.

Ну SIMD есть в D/C3/Odin/Zig/Swift, используй их, Люк.

Ну SIMD есть в D/C3/Odin/Zig/Swift, используй их, Люк.

Так кто спорит-то. Об этом и речь – C не более и не менее low level чем все остальные языки без GC сейчас.

оптимизации не только векторизацию выполняют

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

«Не в казино, а в карты, не выиграл, а проиграл» (ТМ)

В Zig (по-видимому), во многих случаях преобразований можно избежать.

Расту накидали SIMD инструкций под разные процы и все что он делал - определял тип проца и использовал оптимальные SIMD инструкции под него сравнивая с базовой реализацией zlib на С.

В zlib-ng с которым сравнивают прямо написано:

Support for CPU intrinsics when available

    Adler32 implementation using SSSE3, AVX2, AVX512, AVX512-VNNI, Neon, VMX & VSX
    CRC32-B implementation using PCLMULQDQ, VPCLMULQDQ, ARMv8, & IBM Z
    Slide hash implementations using SSE2, AVX2, ARMv6, Neon, VMX & VSX
    Compare256 implementations using SSE2, AVX2, Neon, POWER9 & RVV
    Inflate chunk copying using SSE2, SSSE3, AVX, Neon & VSX
    Support for hardware-accelerated deflate using IBM Z DFLTCC

Никто не попытался прочитать и понять как это тестировалось

Сенсация, обизян не умеет читать:

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

Именно так, и все что сделали в раст версии - лучше и качественные определяли какой SIMD под какой проц будет оптимальнее. Точно также как это делали в бенчмарке ссылку на которую я привёл и там CloudFlare zlib обогнал zlib-ng, по той же причине.

Те это не раст обогнал С, а SIMD обогнал SIMD на конкретном процессоре.

Я либо пропустил ваш комментарий (читаю и отвечаю с телефона) либо одно из двух.

Вы верно описали ситуацию, ЛОР реабилитирован :)

Так их и в Rust можно избежать через #[repr(c)].

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

За поддержку своей деятельности на C они деньги не вымогают. Наверное, потому что и так на зарплате.

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

Линус, что ли? Так он и так вымогает. Уже лет 30 как.

Технически кстати это провокация flame, но почему-то модераторы решили не удалять

Я просто профессионал в этом! И потом, если я не буду набрасывать в Development, то кто будет?

Линус, что ли? Так он и так вымогает. Уже лет 30 как.

Какое вымогательство? Просто грев пацанам.

это провокация flame, но почему-то модераторы решили не удалять

Так жалоб же не было!
Перенёс. Развлекайтесь без анонимусов, они всё равно давно не торты.

Случилось непредвиденное и невероятное:

ты обосрался

Если сделать так:

void xor_swap(int * restrict a, int * restrict b) {
  *a ^= *b;
  *b ^= *a;
  *a ^= *b;
}

то clang сгененрирует такой же код, как и для tmp_swap. С minus_swap аналогично.

Не знаю, может потому что c aliasing.

Аноним был прав. Потому что код в общем случае не эквивалентен (что видно, если, например, вызвать xor_swap(&a, &a))

то clang сгененрирует такой же код, как и для tmp_swap. С minus_swap аналогично.

Ага. Или с -fno-strict-aliasing (не проверял, но прозреваю).

Проблема в том, что большая часть сишников не знают ни про restrict, ни про strict aliasing. Для них указатели – просто числа. И вот это вот говно с xor и вычитанием я имел «счастье» наблюдать в реальном коде.

Аноним был прав. Потому что код в общем случае не эквивалентен (что видно, если, например, вызвать xor_swap(&a, &a))

Тссс! Я-то знаю. А вот сишник Сергей выше – нет, у него суперскалярные процессоры сишечке мешают.

zlib

когда jbig будет, тогда и позовите.

Я вот одного не могу понять - NIH-синдром - это обязательное требование на растофана и rust-программиста или как?