Roc отстаёт от libdeflate всего на 2,6% — и это функциональный язык
How close can pure functional programming get to C?
Автор взял roc-deflate — пакет для DEFLATE-сжатия на функциональном языке Roc — и вручную выжал из него максимум производительности, чтобы сравнить с libdeflate на C. На корпусе Silesia из 144 бенчмарков Roc оказался медленнее в среднем на 8,9% на Ryzen 3900X и всего на 2,6% на M1 MacBook Pro. При этом Roc ещё не выпустил даже версию 0.1.0, а его экосистема почти не оптимизирована.
libdeflate ожидаемо разносит его в пух и прах — ожидаемо, потому что это очень тщательно вылизанная реализация с архитектурно-специфичным SIMD, до которого в Lean нам не дотянуться.
- jandrewrogers
Значительная часть разницы в оптимизируемости связана с тем, что C/C++ позволяет делать довольно экстремальное устранение копирований (copy elision). Это важно, потому что пропускная способность памяти часто становится главным узким местом производительности.
Код на C/C++ может запросто дотянуться до какого-нибудь удалённого бита состояния и напрямую его изменить. Компилятор редко возражает, каким бы уродливым ни был способ или шаблон доступа. Уже программист должен следить за соблюдением инвариантов, и компилятор не всегда может это увидеть насквозь. Однако эти устранённые копирования накапливаются, хотя обычно это ценой сопровождаемости и безопасности.
Это связано с тем, почему функциональные языки на практике часто оказываются посредственными для суперкомпьютеров, несмотря на их хорошие свойства для массового параллелизма в теории.
- VorpalWay
> lean-zip обгоняет каждый уровень сжатия miniz_oxide
Miniz_oxide — это намеренно простая реализация. Было бы справедливее сравнивать её с более новым zlib-rs[1], который даже обгоняет zlib-ng (самую быструю реализацию на C)[2].
[1]: https://lib.rs/crates/zlib-rs
[2]: https://trifectatech.org/blog/zlib-rs-is-faster-than-c/
- gobdovan
Вы не рассматривали возможность вынести эти оптимизации в библиотеку, чтобы программисты могли запрашивать проходы оптимизации, а компилятор проверял предусловия?
Спрашиваю, потому что я готовлю статью о том, насколько быстрым может быть JS, и обнаружил то же самое: можно достичь 10% от оптимизированного кода на C практически с любым кодом, если достаточно помучить V8 (за исключением SIMD, где, похоже, есть баг в V8 — он не оптимизирует в SIMD, даже когда это более чем очевидно). Понял, что мог бы вынести это в библиотеку и сделать более упорядоченно, но не уверен, насколько хорошо ручные преобразования обобщаются.
Кроме того, работая над roc-deflate, вы находили повторяющиеся преобразования, которые вписывались бы в эту модель, или большинство улучшений были специфичны для сжатия?
- ReDress
C действительно является функциональным языком в том смысле, что большинство C-проектов — это вещи, которые наблюдались в реальной жизни и впоследствии были загружены в компьютеры.
Я также хотел бы отметить, что производительность — это АБСОЛЮТНАЯ забота во многих случаях.
Если у вас есть сервер, который делает 10 миллионов запросов к определённому методу в минуту, то вы не можете позволить себе никаких компромиссов по производительности. Вообще никаких.
Rust никогда не заменит C/C++ в области высокопроизводительных вычислений.
- johnny22
говорить, что это "обгоняет крейт, который был скачан X раз" — это не говорит ничего, кроме того, что он популярен. Было бы неплохо увидеть там чуть больше подробностей.