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

а у тебя в асме он также выкинул весь твой код и оставил 3 movl?

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

Ага. Раньше других языков кроме C в ядре не было. Реально первый раз.

0000000000001100 <tmp_swap>:
    1100:       8b 07                   mov    (%rdi),%eax
    1102:       8b 0e                   mov    (%rsi),%ecx
    1104:       89 0f                   mov    %ecx,(%rdi)
    1106:       89 06                   mov    %eax,(%rsi)
    1108:       c3                      ret
    1109:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

0000000000001110 <xor_swap>:
    1110:       8b 07                   mov    (%rdi),%eax
    1112:       33 06                   xor    (%rsi),%eax
    1114:       89 07                   mov    %eax,(%rdi)
    1116:       33 06                   xor    (%rsi),%eax
    1118:       89 06                   mov    %eax,(%rsi)
    111a:       31 07                   xor    %eax,(%rdi)
    111c:       c3                      ret
    111d:       0f 1f 00                nopl   (%rax)

0000000000001120 <minus_swap>:
    1120:       8b 06                   mov    (%rsi),%eax
    1122:       03 07                   add    (%rdi),%eax
    1124:       89 07                   mov    %eax,(%rdi)
    1126:       2b 06                   sub    (%rsi),%eax
    1128:       89 06                   mov    %eax,(%rsi)
    112a:       29 07                   sub    %eax,(%rdi)
    112c:       c3                      ret

Как видишь, нет. Сборка:

$ cat lib.c
void tmp_swap(int *a, int *b) {
  int tmp = *a;
  *a = *b;
  *b = tmp;
}

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

void minus_swap(int *a, int *b) {
  *a = *a + *b;
  *b = *a - *b;
  *a = *a - *b;
}

$ cat lib.h
#pragma once

extern void tmp_swap(int *a, int *b);
extern void xor_swap(int *a, int *b);
extern void minus_swap(int *a, int *b);

$ cat main.c
#include "lib.h"

int main(void) {
  int a = 1, b = 2;

  int iters = 1024 * 1024 * 1024;
  while(iters--)
    minus_swap(&a, &b);

  return 0;
}

$ clang lib.c -O2 -shared -o libswap.so
$ clang main.c -lswap -L. -O2 -o main
$ export LD_LIBRARY_PATH="."
 

Компилятор не может выкинуть код твоей функции или заинлайнить его, если он его не видит (:

А теперь ВНИМАНИЕ вопрос: если сишечка – низкоуровневый язык, куда делась лишняя переменная-то? Что это за выкрутасы такие?

А этот zlib-rs - перевод сишной реализации на rust или своя реализация с нуля?
Оригинальная реализация zlib далеко не самая быстрая
Пахнет очередным набросом

Чтоб писать низкоуровневые вещи.

Ты строчкой ниже говоришь что он не низкоуровневый.

очень легко. Он поэтому в своё время так и взлетел: достаточно низкоуровневый и при этом переносимый на другое железо

Ты только что сказал что он вообще не отражает работу современных CPU. Какой же он тогда низкоуровневый?

Прикольно, что в рублях это 8 651 925,50 р.

Там не наброс, там авторы говорят «дайте нам 9 миллионов рублей и никто не пострадает!»

ну эти все «скорости» - ни о чем.

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

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

Там не наброс, там авторы говорят «дайте нам 9 миллионов рублей и никто не пострадает!»

Люди хорошую вещь сделали, почему бы их не проспонсировать?

не отражает работу современных CPU

я говорил о пенальти, конвеерах, предсказаниях и т.д.

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

а совсем низкоуровневые вещи продолжают писать на асме

Случилось непредвиденное и невероятное: реализация библиотеки zlib на Rust (zlib-rs) обогнала реализацию на C по скорости распаковки и показывает примерно схожую с последней скорость запаковки данных. Разница в производительности может достигать аж 14%.

Вангую на в двое большем потреблении памяти.

я говорил о пенальти, конвеерах, предсказаниях и т.д

Конечно. То есть все то, на чем держится современный перфоманс. Если C этого не может, то что он вообще может? Зачем его использовать?

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

Конечно изменилось, CPU научились обрабатывать больше одной инструкции за раз. А C – нет.

а совсем низкоуровневые вещи продолжают писать на асме

А высокоуровневые – на Rust.

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

Что именно там не изложено? Ссылки на код, который они собирали, там есть.

зацени до чего дошел прогресс

ага, переписанный с сишечки софт стабильно быстрее, и при этом можно не пердолиться с недопереассемблером из 70х

представляю какой это ад делать компиляторы

э э.. так потому и ад, что и компилятор должен быть «долбанным гением искусственного интелекта» что-бы сиха хоть как-то не отставала от раста, и плюс ещё программист должен усираться

Если C этого не может

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

CPU научились обрабатывать больше одной инструкции за раз. А C – нет

ну что за глупости? Си не обрабатывает инструкции.

А оптимизатор в курсе и расставляет инструкции в правильном порядке.

высокоуровневые – на Rust

на яваскрипте, желательно с электроном! :)

переписанный с сишечки софт стабильно быстрее

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

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

А это во всех языках так. В расте работает примерно тотже оптимизатор, что и для сей

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

Ага. Раньше других языков кроме C в ядре не было. Реально первый раз.

C++ пытались применить и.. выкинули. Так что верно, не было. Но неверно, не в первый раз.

C++ пытались применить и.. выкинули. Так что верно, не было. Но неверно, не в первый раз.

Не пытались. В официальном репозитарии, насколько мне известно, плюсов никогда не было.

Прикольно что цифра чисто из методички по маркетингу. Ну типа не целых €100.000 а всего лишь €95.000. Ну как на ценниках в магазине - «теперь всего за 95.00!» Маркетинг во все поля, прям сходу и ни разу не палясь типа. :)

Наверно у них в Rust Evangelism Task Force методички маркетологами написаны.

C++ пытались применить и.. выкинули. Так что верно, не было. Но неверно, не в первый раз.

Не пытались. В официальном репозитарии, насколько мне известно, плюсов никогда не было.

here

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

А почему Rust может? Почему плюсы могут? Потому что это важно для любого современного языка.

ну что за глупости? Си не обрабатывает инструкции.

C должен генерировать код, который должен это учитывать. Он этого не делает.

А оптимизатор в курсе и расставляет инструкции в правильном порядке.

Нет.

на яваскрипте, желательно с электроном! :)

Я же написал, на Rust. Зачем передергиваешь?

Ага, я видел это. Код где?

Алсо, в 1992 году лялекс был просто очередным хобби-проектом. Сорян, не считается.

any compiler or language that likes to hide things like memory allocations behind your back just isn’t a good choice for a kernel

Забавно, в контексте хруста, видимо, нещитово

Ага, я видел это. Код где?

Сам не знаю. Но, говорят, пытались.

Ну, то есть, Торовалтос в 22 года не осилил C++. Это называется «пытались». Угу.

он и руст неосилит. и тоже выкинет.

он и руст неосилит. и тоже выкинет.

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

А почему Rust может

в каком месте? он ещё более высокого уровня абстракции от железа чем си

должен генерировать код, который должен это учитывать

посмотри архитектуру llvm и удивись, что для си и раста там оптимизатор один и тотже, как и для всех остальных языков :)

Он этого не делает.

инструкции в правильном порядке.

Нет

Пример кода будет? Или ссылка на багрепорт?

чегой-то, утиль вот накатал https://github.com/torvalds/subsurface-for-dirk половина на плюсцах, т.е. по сторонам-то он глядит

Так это не в 22 он сделал.

в каком месте? он ещё более высокого уровня абстракции от железа чем си

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

посмотри архитектуру llvm и удивись, что для си и раста там оптимизатор один и тотже, как и для всех остальных языков :)

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

Ну, то есть, Торовалтос в 22 года не осилил C++. Это называется «пытались». Угу.

Не могу знать, что он осилил. Но это ведь не мешает предпринимать попытки его использовать, верно?

судя по изложению по ссылке, рустята пытались превзойти сишные реализации, определенно ради медийного эффекта и даже привязались к конкретному процу.

смешное

Last time, we benchmarked using the target-cpu=native flag. That gave the best results for our implementation, but was not entirely fair because our rust implementation could assume that certain SIMD capabilities would be available, while zlib-ng had to check for them at runtime.

We have now made some changes so that we can efficiently select the most optimal implementation at runtime too.

то есть они пока не сделали рантайм определение проца. а на этот момент, проц зашит в код. а сишный код смотрит это в рантайме.

Picking the best version of a function is known as multiversioning. We have a baseline implementation that works on all CPUs, and then some number of specialized versions that use SIMD instructions or other features that may or may not be available on a particular CPU. 

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

короче лютый ансейф с заточкой под разные архитектуры… там от руста одно название уже.

непонятно с кем и чем соревновался этот ваш раст.

В каждом цикле бенчмарка запускался растовый бенчмарк собранный с растовой прокладкой к системной zlib-ng в zlib-compatible режиме который загружал сишную либу и читал файлик с диска, а потом сразу же запускался растовый бенчмарк скомпилированный сразу с растовым велосипедом без прокладок который загружал тот же файлик который уже был в дисковом кеше. В https://github.com/trifectatechfoundation/zlib-rs/blob/main/zlib_benchmarks.json написано же.

например, в std есть SIMD

Ну в C++26 вроде тоже внесли, мож и в Си внесут. Но я не уверен, что это прям вот настолько сильно мешает оптимизатору

Но это ведь не мешает предпринимать попытки его использовать, верно?

Не знаю про попытки ничего. Код есть в ядре? Кода на плюсах в ядре нет.

https://github.com/silentcedar/linux-0.95

Вот копия версии из 1992 года. Найди там C++, пожалуйста.

Я тоже такого кода не видел, всё так.

Хотел лишь сказать, что попытки использовать ЯП кроме С были.

Ок, со слов Линуса.

Хотел лишь сказать, что попытки использовать ЯП кроме С были.

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

Ну в C++26 вроде тоже внесли, мож и в Си внесут

А может и не внесут. Сейчас этого там нет.

Но я не уверен, что это прям вот настолько сильно мешает оптимизатору

Не помогает.

«The initial development of zlib-rs was started and funded by the Internet Security Research Group as part of the Prossimo project.»

«The initial development of zlib-rs was started and funded by the Internet Security Research Group as part of the Prossimo project.»

Ну вот, хотят часть 2. Это же здорово – пишешь опенсурс, а тебе ещё и платят за это?

Но я не уверен, что это прям вот настолько сильно мешает оптимизатору

Вклинюсь в ваш диалог. Работа с массивами в Си очень и очень трудно оптимизируется. Для типичного цикла for(...) {...} с проходом по массиву для оптимизации в SIMD компилятор должен доказать, что каждая итерация будет абсолютно независимой и не повлияет на другие. Это всё рушится, если задействованы указатели. Особенно если вызывается внешняя функция и ей передаётся указатель на элемент массива, ведь она в теории может обращаться к другим элементам этого массива.

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

А чего у них на графиках какая-то странная единица измерения - циклы, а не более практичные МБ/с?

Ну так не своими силами, а таки на гранты

не знаю как в процентах по скорости, но сишному коду не надо 95 тыс. фунтов, чтобы работать уже сейчас.

то есть, тут сишечка недосягаема :)

не знаю как в процентах по скорости, но сишному коду не надо 95 тыс. фунтов, чтобы работать уже сейчас.

Потому что на него куда больше уже потратили. Включая анализ на дыры, траты на закрытие этих дыр, обновления и т.д. Из-за проблем с безопасностью, сишка – очень дорогой язык. Это одна из причин, почему все так к Rust присосались-то. Реально бабло экономит!

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

ну есть стандартный openmp и пока не стандартные реализации simd

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

ну есть стандартный openmp и пока не стандартные реализации simd

Ты хоть раз видел сишный код с openmp в живую? Я вот нет. Вообще ни разу.

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

Там идёт сравнение в том числе с реализацией из Chromium, которая:

1. не древняя
2. используется на тех же платформах, что и Rust, потому что хромог не то чтобы сильно портирован куда-то
3. постоянно оптимизируется чуваками из Гулага

Ты хоть раз видел сишный код с openmp

видел, но ровно один раз :)

а вобще darktable и tensorflow вроде его используют