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

скорость генерации увеличило примерно в 1000 раз
и увеличил ещё в 100 раз

Итого, в 100000 раз? А должно быть в 100500.

Нет, это не так работает. Итого примерно в 100 раз получилось.

Ключевой термин «conforming program». Половина сишного кода поражена UB.

Дык. Это не проблема совместимости со стандартом. Так что должно быть не

Сделать совместимую со стандартом реализацию Си – достаточно сложная задача

А «Сделать реализацию, которая не сломает кучу существующего кода завязанного на поведение существующих компиляторов - достаточно сложно»

А что есть проще C? Ассемблер?

Oberon A2 © – проще и человекоориентированнее :)

4.2. Не раст обогнал Си, а zlib-rs обогнал zlib на Си.

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

Зависит от целей и задач.

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

Если код некачественный - претензии к кодерам.

Ичо?

Всё же чётко сказано - страдает эффективность.

Это всё равно получается безопаснее чем писать на Си.

Сравниваете тёплое с мягким.

Если почитаешь код, там unsafe всего несколько функций.

Вангую, что если поставить unsafe там, где он не используется, безопасность не пострадает. Хотя опять же, это мнение, а не факт.

Если код некачественный - претензии к кодерам.

Ну, да. Всё верно. Так как сишники не осиливают раст, то выкинуть сишку – лучшее средство против говнокодеров.

Всё же чётко сказано - страдает эффективность.

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

Вангую, что если поставить unsafe там, где он не используется, безопасность не пострадает. Хотя опять же, это мнение, а не факт.

Зачем ставить unsafe, если он не нужен?

pascal, ada, lisp, tcl…

Ada огромна и жирна, и включает в себя многопоточную модель, ООП и так далее. Lisp и Tcl требуют сборщик мусора, макросы и интерпретацию. Сразу мимо.

Есть. tailgunner

пффф шейдеры легко обгоняют ассемблер

Последнее посещение: 16.03.22 12:30:06 GMT

Это называется «нет».

шейдеры легко обгоняют ассемблер

внезапно там тоже бывает ассемблер - DirectX Shader Assembly Language или Adobe Graphics Assembly Language, так что нет, ассемблер он и есть ассемблер, даже если назвали по-другому :)

Ну и там же где то диалекты сишечки - Cg и GLSL

И так-то шейдер - это программа для gpu, а ассемблер - язык, обогнать шансов нет)

DirectX Shader Assembly Language или Adobe Graphics Assembly Language

депрекатед оба, первый ещё и оффтоп

шейдер - это программа для gpu

имелись в виду языки написания шейдеров

диалекты сишечки

примерно, как раст, ага - общего примерно столько же

ну на расте я как-то небольшой проект писал, на шейдерах нет

но про Cg/HLSL четко написано - based on C

а Rust точно не based, там от си только фигурные скобки

то выкинуть сишку – лучшее средство против говнокодеров.

Они просто будут писать на расте.

Не, не страдает.

Тогда зачем на комментарий об эффективности отвечать про безопасность.

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

Сколько раз сказано, что это zlib-rs обогнал обычный zlib, а не rust обогнал C.

Зачем ставить unsafe, если он не нужен?

Я имел в виду, что в тех участках кода, где не используется unsafe, проблем не будет, даже если будет использоваться unsafe. Т. е. я предположил, что безопасность zlib-rs не уменьшится, если бы его переписать на Си.

Они просто будут писать на расте.

Не будут. Иначе бы уже писали.

Сколько раз сказано, что это zlib-rs обогнал обычный zlib, а не rust обогнал C.

Если код на Rust показывает производительность выше чем код на Си в куче случаев, то Rust обногяет Си. Всё верно.

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

Чо? Участки без unsafe избавлены от проблем с памятью, потому что их проверил компилятор. Ты предлагаешь сначала написать без unsafe, проверить что всё верно, а потом завернуть в unsafe? Какая-то очень тупая идея.

Т. е. я предположил, что безопасность zlib-rs не уменьшится, если бы его переписать на Си.

Это в корне неверное предположение.

Т. е. я предположил, что безопасность zlib-rs не уменьшится, если бы его переписать на Си.

Если код на раст автоматически транслировать в C, то да, не уменьшится. Если ручками переписывать, то errare humanum est.

Если ручками переписывать, то errare humanum est.

Так и на расте кодер может совершить ошибку.

Так и на расте кодер может совершить ошибку.

Может. Но, повторюсь, компилятор Rust проверяет ошибки памяти. А сишный не проверяет.

Не будут.

Будут. Если просто заменить Си на Rust, то что им помешает писать bad code?

Иначе бы уже писали.

Откуда такая уверенность? Чисто технически, использование unsafe тоже является признаком некачественного кода.

Ты предлагаешь сначала написать без unsafe, проверить что всё верно, а потом завернуть в unsafe?

Нет, я иными словами сказал, что код на rust не стал бы безопаснее АНАЛОГИЧНОГО на Си.

Это в корне неверное предположение.

С чего ради? Вы же сами сказали, что rustc проверил код на проблемы с памятью.

А потом кодер ставит unsafe.

Будут. Если просто заменить Си на Rust, то что им помешает писать bad code?

Что такое bad code? Rust защищает от ошибок памяти. В случае с Rust, писать код с ошибками памяти мешает компилятор.

Нет, я иными словами сказал, что код на rust не стал бы безопаснее АНАЛОГИЧНОГО на Си.

Вопрос в стоимости и сложности написания АНАЛОГИЧНОГО кода.

С чего ради? Вы же сами сказали, что rustc проверил код на проблемы с памятью.

Ага. В коде на Rust. В коде на C rustc проверить код не ошибки памяти не может, поэтому гарантии отзываются.

А потом кодер ставит unsafe.

Это очень тупой кодер, если он суёт unsafe где не требуется.

Это очень тупой кодер, если он суёт unsafe где не требуется.

Т.е. 95% кодеров. :)

Что такое bad code?

овнокод, иными словами.

Rust защищает от ошибок памяти.

Но не защищает от неэффективного кода.

писать код с ошибками памяти мешает компилятор.

Повторюсь, unsafe поставить никто не мешает.

Т. е. ваш тезис:

то выкинуть сишку – лучшее средство против говнокодеров.

не является верным.

Ага. В коде на Rust. В коде на C rustc проверить код не ошибки памяти не может, поэтому гарантии отзываются.

Так а смысл, если код на Си аналогичен коду на Rust?

Это очень тупой кодер, если он суёт unsafe где не требуется.

Ну т. е. вы пришли к противоречию самому себе - то ради избавления от тупых кодеров нужно избавиться от Си, то они всё-таки будут писать на расте.

Rust защищает от ошибок памяти.

Но не защищает от неэффективного кода.

Кто-то утверждал обратное?

писать код с ошибками памяти мешает компилятор.

Повторюсь, unsafe поставить никто не мешает.

Т. е. ваш тезис:

то выкинуть сишку – лучшее средство против говнокодеров.

не является верным.

Уточню: выкинуть сишку – лучшее средство от сишных говнокодеров. У них аллергия на Rust. Это не техническое свойство Rust, а социальное.

Так а смысл, если код на Си аналогичен коду на Rust?

Но код на Си не аналогичен Rust, особенно если переписан руками человеком, который мог наделать ошибок.

Нет указателей и их аналогов, нет динамической памяти вообще, нет UB, goto, стандартной библиотеки и другой препроцессор. Зато есть типы данных фиксированного размера, встроенные векторные типы данных и сквизинг.

От C там внешний вид какого-нибудь цикла for, но оно и в С++ и в Java и в С# выглядит совершенно одинаково.

Но ты-то не такой.

Кто-то утверждал обратное?

Кто-то утверждал, что некачественный код исчезнет, если выкинуть сишку.

Уточню: выкинуть сишку – лучшее средство от сишных говнокодеров

Спасибо, Капитан Очевидность! А выкинуть раст - лучшее средство от растовских. А если выкинуть программирование, то некачественный код перестанет существовать как явление.

Но код на Си не аналогичен Rust,

Это смотря как рассматривать. В чём проблема написать код на Си, при котором программа будет работать с памятью так же, как если бы она была на расте (читай: портировать код с раста на C)?

Кто-то утверждал, что некачественный код исчезнет, если выкинуть сишку.

Где?

Спасибо, Капитан Очевидность! А выкинуть раст - лучшее средство от растовских.

Да, но такой задачи не стоит.

В чём проблема написать код на Си, при котором программа будет работать с памятью так же, как если бы она была на расте (читай: портировать код с раста на C)?

В чём проблема писать код, который не срёт в память и не сегфолтится? Проблемы две:

1. Си – очень дерьмовый язык с вагоном undefined behaviour (список на 10 страниц A4 в стандарте, не шучу);
2. Руки у программистов на Си прямотой зачастую не отличаются, зато гонора – впереди планеты всей.

Где?

Здесь:

Так как сишники не осиливают раст, то выкинуть сишку – лучшее средство против говнокодеров.

А выкинуть раст - лучшее средство от растовских.

Да, но такой задачи не стоит.

А чем плохие кодеры на Си хуже плохих кодеров на Rust? Разве что в некачественном коде на Си выше вероятность утечки памяти.

Руки у программистов на Си прямотой зачастую не отличаются

Статистика есть?

зато гонора – впереди планеты всей.

Кажется, вы не знакомы с коммьюнити Rust.

Здесь:

Так как сишники не осиливают раст, то выкинуть сишку – лучшее средство против говнокодеров.

Я уже уточнил выше: против сишных говнокодеров.

А чем плохие кодеры на Си хуже плохих кодеров на Rust? Разве что в некачественном коде на Си выше вероятность утечки памяти.

Тем, что код плохих кодеров на Си сегфолтится. Причём не всегда сразу, иногда после сборки новым компилятором, ибо UB.

С Rust такого не происходит.

Статистика есть?

https://www.cve.org/CVERecord/SearchResults?query=buffer+overflow

Кажется, вы не знакомы с коммьюнити Rust.

Ксо жалению, знакомы. Сишники всё ещё похуже будут.

Тем, что код плохих кодеров на Си сегфолтится. Причём не всегда сразу, иногда после сборки новым компилятором, ибо UB.

Аргумент против Си, а не против плохих сишных кодеров.

https://www.cve.org/CVERecord/SearchResults?query=buffer overflow

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

Сишники всё ещё похуже будут.

Значит, у нас разный жизненный опыт.

Аргумент против Си, а не против плохих сишных кодеров.

А они связаны. Плохих сишные кодеры отказываются учить что-то кроме Си (и может C++).

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

По оценкам того же гугла, причина порядка 70% багов в хромоге – ошибки работы с памятью. И если гугел не осилил выдрессировать стадо сишников чтобы они писали код без багов, то кто вообще сможет их выдрессировать-то?

По оценкам того же гугла, причина порядка 70% багов в хромоге – ошибки работы с памятью

Ждём когда гугл запустит свои лапы в CHERI.

Остаётся паскаль…

Ждём когда гугл запустит свои лапы в CHERI.

Зачем он им для хромога? Они скорее на тот же Rust его перепишут.

Остаётся паскаль…

Самое тупое, что никто до сих пор не допёр сделать «Си без UB». Это уже был бы гораздо лучший язык чем то что есть. Глядишь, и строки в стандартную библиотеку бы добавили.

но не в UE 5 :(

Самое тупое, что никто до сих пор не допёр сделать «Си без UB». Это уже был бы гораздо лучший язык чем то что есть.

С какими UB в языке Си вы чаще всего сталкивались?

Плохих сишные кодеры отказываются учить что-то кроме Си (и может C++).

Если вы видели какого-то клоуна, который отказывается учить другие языки, то это не значит, что все плохие сишные кодеры такие.

По оценкам того же гугла, причина порядка 70% багов в хромоге – ошибки работы с памятью.

Соотношение багов != соотношение качества ВСЕГО кода. Этих багов может быть пруд пруди, а может быть, их частота появления нормальна для такого мастодонта, как хром.

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

Зачем он им для хромога? Они скорее на тот же Rust его перепишут.

Ну гугл не хромым един, для мобилок пойдёт.

Самое тупое, что никто до сих пор не допёр сделать «Си без UB». Это уже был бы гораздо лучший язык чем то что есть.

Так это, сделай.

Это нереально. Видите код:

for(int i = 0; i < size; i++) func();

Вот здесь уже UB

А кто сказал, что авторы zlib на С гнались за скоростью?

Ну, вот, собственно, и ответ почему так. Читаем по ссылке.

Decompression

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.

То есть, в переносимости растаманы уже потеряли. Ну оно и немудрено. Мой коллега реализовал вычисление SHA256 с использованием SHA-NI инструкций и SIMD. Ну да, реализация рвет по перформансу все подряд как тузик грелку. Ну и чо? Сколько процессоров это все имеют на борту?

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

Вместо того чтобы скомпилировать сишную версию с SIMD и сравнить яблоки с яблоками?

Как-то после этого остальное читать не интересно. У проектов тупо разные цели. У одних была цель сделать что-то полезное, и сделанного оказалось достаточно для повседневного применения, а у других — придумать новый вид спорта и в нем всех победить. Ну типичный ход маркетоидов, чо. «А зато мы чемпионы по прыжкам в сторону».

https://www.cve.org/CVERecord/SearchResults?query=buffer+overflow

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

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

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

все UB сишки, это «UB» железки на которой крутится код. Вот только почему-то никто не говорит про железку, что деление на ноль это UB. А просто говорят, что деление на ноль вызывает прерывание по такому то вектору, ибо сие есть запрещенная операция. И ровно так же запрещена эта операция в Си(патетически названная UB). и по другому быть не может.

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

и да и да

Rust и Си одно и тоже - языки имплементации не очень подходящие сами_в_себе для ресёча-прототипи если конечно альтернатива не асм если ваще не машикод

и претензии к Си изначальные что это асм выглядищий как структурный язык - хотя даже парсер(как и у фортрана) не очень то и топ-даун-рекурсивный в отличии от божественых Алгол-Паскалей

а так как асм то и претензии в обмане ожиданий - синтаксически есть массивы а семантически это адреса и какой то авто выделенее но не более - крч продвинутый асм

rust в свою очередь модно молодёжный но тоже это асм

все UB сишки, это «UB» железки на которой крутится код.

А как же мой любимый пример с указателями? https://godbolt.org/z/nfTvG1xhh

Где тут UB железки?

и все сишеченые «пороки» это пороки ассемблера, которые имеют чисто железячные причины.

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

или уйти в бесконечный цикл на много часов, спалив процессор

Какой то инженер Intel говорил, что если вы не разогреваете процессор на 100C то мощности зря простаивают. У меня процессор и день может на близких к 100C работать.

все UB сишки, это «UB» железки на которой крутится код

INT_MAX + 1 это UB. Никаких прерываний и запретов со стороны железа нет.