Если программист посчитал, что в данном месте нужен ассерт, значит так оно и надо.

Разве при сборке с NDEBUG assert не выбрасывается? Ведь тогда вызова функции не произойдёт. Или я что-то путаю?

Ну на расте там реально говнокод. Сразу видно, что человек видит раст впервые. Можно раза в два короче сделать.

Более того тут пишут:

и продолжение цитаты

as long as 1) for now it wasn't enabled by default (even if you did «make allyesconfig») so that people don't *need* Rust to build the kernel

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

Звучит как саботаж.

в кернеле их нет

В расте «анальные огораживания» никак не завязаны на рантайм ОС или еще какие-то внешние механизмы, так что твое заключение логически не несет никакого смысла.

получился аналог самой обычной сишечки

За исключением всех статических и не очень гарантий которые дает раст, смотри пункт 1.

да ещё и на чужом компиляторе

А, фанклуб Царя, ясно, до свидания.

А, фанклуб Раста, ясно, до свидания.

Я правильно понимаю, что эти типа компьютер саентисты сравнили скорость работы memcpy, написанной на Си и вызванной из разных ЯП, и на основании того, что она везде работает примерно одинаково сделали вывод о том, что некотороые ЯП работают не хуже чистого Си?

Абсолютно не тенденциозное исследование, чё!

Не увидел в ржавой реализации си-шного memcpy.
А так, там конечно вызываются memmap и ioctl плюс ещё парочка системных вызовов.
Но придираться к этому примерно как до столба докапываться.

Другое дело в java-реализации они там зачем-то читали /proc через jni, которое само по себе ещё тот тормоз.

За исключением всех статических и не очень гарантий которые дает раст, смотри пункт 1.

Те, что не очень, можно и с си/плюсами получить: -fsanitize=address.

Вызов memcpy генерируется компилятором...

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

Однако, выводы она сделали языках.

везде работает примерно одинаково

не везде, только там где есть IOMMU

https://www.kernel.org/doc/Documentation/vfio.txt

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

Пруф?

https://clang.llvm.org/docs/AddressSanitizer.html

Typical slowdown introduced by AddressSanitizer is 2x.

AddressSanitizer uses more real memory than a native run. Exact overhead depends on the allocations sizes. The smaller the allocations you make the bigger the overhead is.

AddressSanitizer uses more stack memory. We have seen up to 3x increase.

On 64-bit platforms AddressSanitizer maps (but not reserves) 16+ Terabytes of virtual address space. This means that tools like ulimit may not work as usually expected.

Static linking of executables is not supported.

Получайте.

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

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

В итоге для java замерили работу сборщика мусора. Молодцы, что. :-)

Интересно было бы посмотреть результаты на GraalVM с native-c API, думаю скорость была бы на уровне сей. И код был бы чище и всё на джаве, без JNI.

а в java вкрутили jni (который сам по себе тормоз)

А есть альтернативы?

GraalVM и native-c API, фактически всё можно было на джаве написать, без уродства с JNI.c

Лучше бы вы на «басе» играли, вместо того чтобы делиться сокровенной мудростью на LOR.

На amd64 (gcc):

14 	    b = a;
0x55555555514e	lea    rax,[rbp-0x400]
0x555555555155	lea    rdx,[rbp-0x200]
0x55555555515c	mov    ecx,0x40
0x555555555161	mov    rdi,rax
0x555555555164	mov    rsi,rdx
0x555555555167	rep movs QWORD PTR es:[rdi],QWORD PTR ds:[rsi]

На AVR (gcc):

1195	    b = a;
=> 0x00006f3a <+44>:	ldi	r18, 0x20	; 32
   0x00006f3c <+46>:	movw	r24, r28
   0x00006f3e <+48>:	adiw	r24, 0x01	; 1
   0x00006f40 <+50>:	movw	r30, r24
   0x00006f42 <+52>:	movw	r26, r28
   0x00006f44 <+54>:	adiw	r26, 0x21	; 33
   0x00006f46 <+56>:	ld	r0, Z+
   0x00006f48 <+58>:	st	X+, r0
   0x00006f4a <+60>:	dec	r18
   0x00006f4c <+62>:	brne	.-8      	;  0x6f46 <main+56>

OK, оно сгенерировало саму memcpy, а не вызов…

Ну основная суть то в статических, про существование рантаймовых санитайзеров для си/крестов я в курсе.

Typical slowdown introduced by AddressSanitizer is 2x.

Конечно, не бесплатно. Но и в расте тоже. Какие там числа для bound checker'а в рантайме? Наверное, разброс может оказаться таким как при использовании GC (да, одним и тем же для того же кода, но слишком разным для по-разному написанному коду, который выдаёт тот же результат).

Также интересен оверхед раста по остальным параметрам.

Static linking of executables is not supported.

Статическая линковка при использовании glibc и так имеет ограничения.

Кстати, из свеженького в Debian:

gtk+2.0 (2.24.32-4) unstable; urgency=medium
...
  * Disable the static library.
    The static library is not useful in practice, because its dependencies
    atk, gdk-pixbuf and pangocairo are only available as shared libraries.
    If a derived executable can use those shared libraries, then it can
    equally well use the shared GTK library.
...
 — Simon McVittie <cut>  Wed, 11 Sep 2019 22:03:10 +0100

Какие там числа для bound checker’а в рантайме?

В реальных приложениях - доли процента. Если программа только и делает, что дёргает массив - то прилично, да.

Также интересен оверхед раста по остальным параметрам.

Каким параметрам? Всё остальное как в C/C++.

project panama, но она пока не доехала до релиза.

Наверное, разброс может оказаться таким как при использовании GC

Какие у нас языки с GC, но без bounds checking? А то будем сравнивать оверхед BC в расте с оверхедом в несуществующем языке с GC, но без BC.

Впрочем, этот оверхед слишком зависит от конкретного кода и может меняться от полного отсутствия (оптимизатор выкинул) до десятикратного замедления (BC сломал векторизацию, лечится использованием итераторов). Так что об оверхеде BC «в общем» особого смысла рассуждать нет.

Также интересен оверхед раста по остальным параметрам.

Использование памяти: никаких лишних полей в структуры данных не кладётся. Написал struct Foo { a: u32 }, получил структуру размером 4 байта. В enum есть неявное поле тэга, которое в некоторых случаях может быть включено в данные. Например, size_of(Option<u8>) = size_of(Option<Option<u8>>) = 2.

Как и C можно сделать упакованную (packed) структуру.

Между элементами в массивах только паддинг (если нужен). Как и в С.

Использование стека: тоже ничего неявного не делается. Какие локальные переменные прописаны, те и кладутся в стек.

16ТБ адресного пространства не мапит без спроса. Статическую линковку позволяет.

А что оно по твоему должно делать? Святым духом байты копировать?

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

Так что об оверхеде BC «в общем» особого смысла рассуждать нет.

Как и с GC.

Написал struct Foo { a: u32 }, получил структуру размером 4 байта. В enum есть неявное поле тэга, которое в некоторых случаях может быть включено в данные. Например, size_of(Option<u8>) = size_of(Option<Option<u8>>) = 2.

Уверен, что инструментирование кода gcc осуществляет таким образом, что оно прозрачно. Т.е. добавки не видны и не влияют на результат (если код корректен).

В реальных приложениях - доли процента. Если программа только и делает, что дёргает массив - то прилично, да.

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

Каким параметрам? Всё остальное как в C/C++.

Память, стек,.. Из-за подключения санитайзера.

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

Ну я придирался не к Rust, а к горе-исследователям, которые делают суждения о качестве тех или иных языков на основании скорости работы memcpy (хорошо, сгерерированных аналогов memcpy), memmap, ioctl...

Хотите оценивать языки - делайте CPU-bound-тесты с минимумом вызовов библиотечного кода.

Хотите оценивать языки - делайте CPU-bound-тесты с минимумом вызовов библиотечного кода.

Это да.

Недавно добавили поддержку PGO, но походу что-то не осилили, потому что заметил интересный тред в рассылке

http://lists.llvm.org/pipermail/llvm-dev/2019-September/135078.html

А зачем вам санитайзер в расте?

При компиляции gcc появляется всё больше предупреждений из статических проверок.

Борроу-чеккер всё равно не выйдет реализиовать. А надёжный софт на расте можно писать прямо сегодня.

Аналогичный динамическому address-санитайзеру функционал в нём есть, значит, нужен не только мне.

А надёжный софт на расте можно писать прямо сегодня.

Это всего лишь один из критериев при выборе инструмента.

D

Какие у нас языки с GC, но без bounds checking?

dmd -boundscheck=off

Какой ещё функционал?

Естественно. Можно ещё вспомнить о наличии вменяемой системы сборки, модулей и прочих прелестей.

boundcheck

Это и в C++ есть. Санитайзеры тут не при чём.

наличии вменяемой системы сборки

У меня кросскомпиляция, например, в винду не работает из-коробки в Debian. А с gcc (mingw-w64), go работает. С go не только в винду i686/x86_64, а ещё и на другие ОС и процессорные архитектуры.

Не потянет ли драйвер на rust, какой-либо специфичный только для rust run-time /и какой/?

А у меня gcc не работает. ЧЯДНТ?

Я о POD и не исключительно о Си++, а о Си тоже.

На что ругается i686-w64-mingw32-gcc/g++?

А при чём тут POD к санитайзерам?

Да я помню. Давно это было. Проще в виртуалке собрать.

Ред сосёт у нормального ФП с нормальной системой типов.

trai_kiyaan ты делаешь в своём противостоянии Rust одну ошибку, не важно какая разница между С++ и Rust, это в конце концов дело вкуса.

Ты правильно подозреваешь, что если раст пройдёт, то ядро на него перепишут полностью и тебе придётся писать на нём.
Но ты не понимаешь почему Rust это произойдёт, а произойдёт это даже если rust будет немного хуже C/С++, потому что главное это не язык, а то что Rust в отличии от gcc поставляется под лицензиями Apache и Mit, а не GPL и связанных с этим лицензионных ограничений не имеет. Вот ради снятия этих лицензионных ограничений Linux и стараются превести на Rust и именно за это ты и должен rust критиковать как попытку украсть коллективную собственность в виде обхода ограничений GPL.

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