В состав находящегося в разработке ядра Linux 5.12 включена реализация механизма KFence (Kernel Electric Fence), который проверяет работу с памятью, отлавливая выход за границы буферов, обращения к памяти после освобождения и другие ошибки подобного класса...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54671
Всё, Раст больше не нужен? (Ну, он и раньше был не нужен, но теперь за него вообще никаких аргументов не осталось)
Благодаря этому инструменту выявятся те участки кода, которые нужно переписать на раст.
Нужно ли? Чтобы добавить оверхед на пустом месте?
А сабж - оверхед не на пустом месте?
Сабж только для разработки и вполне отключается.
Сабж таки позиционируется как годный и для продакшнового применения. Если от KASAN оверхед солидный то от этого уже куда разумнее. Поэтому можно позволить себе избавиться от непонятных барабашек и сделать хакерам неудобно. Если это важнее максимального перфоманса любой ценой.
Если есть проблемы. Если их нет, то и оверхэд ни к чему.
> Если есть проблемы. Если их нет, то и оверхэд ни к чему.Оно как бы да. И все же в проекте ТАКОГО размера уповать на полное отсутствие багов - для оптимистов. А кому безопасность и отсутствие багов важнее - ну вот теперь будет оно, как еще 1 вариант.
Так сабж всегда можно отключить, если дебаг не нужен. При отклюбчении не будет и оверхеда.
Сабж это культ-карго от легковерных туземцев, которые ужас как боятся дыреней.
> Сабж это культ-карго от легковерных туземцев, которые ужас как боятся дыреней.Ну да, это нормально когда у вас приложение вылетает раз в час (сарказм)
Сейчас 2021 год сейчас ничего не вылетает раз в час. Вылезь уже из криокамеры.
> Сейчас 2021 год сейчас ничего не вылетает раз в час. Вылезь уже
> из криокамеры.у меня десяточка стабильно вылетает раз в неделю с синим экраном. Полностью переполз на линукс
Ну дык да, стабильно раз в 10 минут или random time.
> Ну да, это нормально когда у вас приложение вылетает раз в час (сарказм)Это вы про питон наверное, там класть на ошибки норма, поэтому оно в какой-то момент просто осыпается с диким стэктрейсом как раз.
Нене, за карго культом - к растаманам. У них там эрзац пакетного менеджера.
У раста нет оверхеда по сравнению с си на эквивалентном коде. Все его фичи работают во время компиляции.
Это не так, мы уже выяснили.
Сылки на треды, в которых проходило обсуждение
> Сылки на треды, в которых проходило обсуждение"Мы все так говорим, а значит это правда!" (с)
Brotli обсуждали? Вот: https://dropbox.tech/infrastructure/lossless-compression-wit...
Dropbox попробовал переисать на Раст и получилось на 28% медленнее. Причины освещены в статье.
> Brotli обсуждали? Вот: https://dropbox.tech/infrastructure/lossless-compression-wit...
> Dropbox попробовал переисать на Раст и получилось на 28% медленнее.А grep переписали в ripgrep и получилось быстрее. Причем не в абстрактновакуумных конях, а в реальном поиске в 2-3 гиговым репам.
Такие дела, да ...
А мой папа!
Так дети в песочнице хвалятся. А где тесты, где пруфы, где анализ того, почему быстрее... Будем верить на слово.
> А мой папа!
> Так дети в песочнице хвалятся.
> А где тесты, где пруфы,Так дети, пытающиеся казаться взрослыми, умничают, не пытаясь понять смысл прочитанного.
Как и написано - берешь большую репу, берешь time и ищешь. Сравниваешь реальный результат.
> где анализ того, почему быстрее...
Ну да, без анализа реальность данная нам ощущениях (тормозной греп) резко станет неправдой. Хинт: в грепе с параллельным поискоим не очень. И нет, не нужно кивать на распараллеливание xargs - это не очень помогает grеp вырваться вперед (и не работает при поиске в больших файлах). Но если очень хочется именно анализ, то (5 летней давности)
https://blog.burntsushi.net/ripgrep/
> Будем верить на слово.Учитывая, что репы на несколько гигов я как-то и не собирался загружать, толку то в красивых "пруфах" в виде копипасты (или скриншотов, с графиками) запуска time rg <>?
... впрочем, особой разницы с ссылкой выше в смысле повторимости тоже нет.
Если действительно интересно, а не "за по*раться", то тут на форуме не так давно уже были бенчи и сравнения одновременно еще и с ag
см. ветку начиная с #71 https://www.opennet.ru/openforum/vsluhforumID3/118581.html#71 (скрытая модератором подветка тоже содержит бенч)
> ... впрочем, особой разницы с ссылкой выше в смысле повторимости тоже нет.В смысле - данной Вами ссылкой. Ни кода, ни данных на которых тестировали там я как-то не обнаружил. А так-то да, графики красивые.
О, совсем другое дело. Почитаю.
> А grep переписали в ripgrep и получилось быстрее.А кто сказал что там алгоритмы одинаковые были? Вон там сравнили один конкретный алгоритм, одинаковый. Вот это честное сравнение. А две напрочь разные программы - ни о чем.
> Вон там сравнили один конкретный алгоритм, одинаковый.
> Вот это честное сравнение.При этом, один и тот же алгорим может быть реализован разными способами, что существенно влияет на конечный результат
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
× source secs mem
1.0 Rust 0.45 499,168
1.4 C++ g++ 0.63 499,704
1.7 Rust #2 0.75 995,144
1.7 Rust #3 0.78 995,136
1.9 C gcc 0.86 698,264
2.2 C gcc 0.98 994,220
3.1 C gcc 1.41 994,048
...
5.4 C++ g++ #3 2.42 499,964
6.4 C++ g++ #6 2.88 1,505,952
7.6 C gcc #4 3.40 500,236
13 C++ g++ 5.96 979,844
> А две напрочь разные программы - ни о чем.Две разные реализации - собственно тоже.
> При этом, один и тот же алгорим может быть реализован разными способами,
> что существенно влияет на конечный результатОно как бы да, но есть нюансы.
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Вот конкретно это - и правда довольно странная штука. Какая-то синтетическая дичь, где параметры сборки довольно странные. А вот алгоритм сжатия, при нанятом коммерческими корпами прогерах, где работа на результат - все же более реалистичный бенч.
> Две разные реализации - собственно тоже.В общем то да. И все же - одна коммерческая корпа, другая коммерческая корпа, тот же алгоритм, при том не левая синтетика а реально имеющее хождение нечно. И прогерам денег дали чтобы они могли просто пойти и покодить. В обоих случаях.
На самом деле там сам алгоритм довольно средненький, кста, но гугол массой продавил, а автор креативно смухлевал с предзагруженным словарем. Если кого скорость, особенно распаковки волновала, zstd в этом плане интереснее.
Надеюсь вы сами прочитали статью. Dropbox как минимум утверждает, что
1) реализация на Rust была безопаснее реализации на C
2) и "Zeroing memory: Telling the Rust allocator to avoid zeroing the memory when allocating for Brotli improves the speed to 224 MB/s.". Т.е. выключение опции обнуления памяти при освобождении увеличила скорость до 224 MB/с, против 217 MB/s для реализации на C. Упс.
> Надеюсь вы сами прочитали статью. Dropbox как минимум утверждает, что
> 1) реализация на Rust была безопаснее реализации на C
> 2) и "Zeroing memory: Telling the Rust allocator to avoid zeroing the
> memory when allocating for Brotli improves the speed to 224 MB/s.".
> Т.е. выключение опции обнуления памяти при освобождении увеличила скорость до 224
> MB/с, против 217 MB/s для реализации на C. Упс.Там как-то текст "немного по дебильному написан".
;----X8
Currently the decompressor runs at 72% of the speed of the vanilla -O3 optimized Brotli decompressor in gcc-4.9 for decompressing 4 megabyte blocks of data. This means it is able to safely decompress Brotli data at 217 MB/s on a Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz.
;----X8Я эти строки для себя перевёл как:
;----X8
На данный момент декомпрессор работает на 72% от скорости оптимизированного с gcc-4.9 для 4-х мегабайтных блоков. Это означает, что он может декомпрессировать данные Brotli со скоростью 217 МБ/с на ntel(R) Core(TM) i7-4790 CPU @ 3.60GHz.
;----X8Т.е. 217 - это скорость декомпрессора на Rust (которая 72% от скорости C-шного варианта. Потом они отключили обнуление памяти и получили 224 Мб/с. Далее отключив проверки границ и включив unsafe они получили 249МБ/с, или 82% от C-шной реализации. Отсюда C-шная реализация имеет скорость имеет скорость около 300 МБ/с.
И это, gcc 4.9 немного протух. А они не хотят хотя-бы 9..10 взять? А то б еще 2.95 бенчмаркали :)
> И это, gcc 4.9 немного протух. А они не хотят хотя-бы 9..10
> взять? А то б еще 2.95 бенчмаркали :)Там просто статья за 2016 год, тогда максимальная версия gcc была 5.X, но может она в том дистрибутиве, которые они использовали, не поставлялась.
Да, похоже на то. Они как-то коряво написали, но дальше однозначноActivating unsafe mode results in another gain, bringing the total speed up to 249MB/s, bringing Brotli to within 82% of the C code.
Так что да, rust медленнее.
> Далее отключив проверки границ и включив unsafe они получили 249МБ/с, или
> 82% от C-шной реализации. Отсюда C-шная реализация имеет скорость имеет
> скорость около 300 МБ/с.Что-то не выглядит эпично. Профакать треть скорости, поотключать все фичи безопасности и все равно не догнать.
Так то понятнее чего растаманов увольняют: на треть больше серваков ставить жаба душит, а если там unsafe везде и все такое - а в чем профит этой камасутры был? "Зато на расте"? oO
Smart_pointer - это разве не оверхед? Каждое обращение к памяти со спинлоком!
у тебя весь код состоит из смартпоинтеров?
Самое место внутри IRQ :D
"Но у меня на виртуалке работает!" :D
Оверхед, но никаких спинлоков там нет. Проблема там в том, что умные указатели плохо оптимизируются, но от этого страдают и кресты в той же степени.
Я имел ввиду Thread Safety смарт поинтера. Если не спинлок то атомик, хрен редьки не слаще.Ой.. позновато прочитал.
О каких умных указателях ты говоришь?Обычные ссылки (&T, &mut T) имеют в рантайме оверхеда даже меньше чем обычные указатели, ибо у них намного более строгие правила алиасинга
Box оверхед имеет только на этапе компиляции, в рантайме это тот же malloc/free
Rc имеет оверхед Box + подсчёт ссылок через inc/dec
Arc - тот же Rc, только подсчёт ссылок атомарныйТаким образом оверхед ты задаёшь явно, и там где надо можешь обойтись без него
Ни о каких спинлоках речи не идёт, если ты сам не создашь свой умный указатель со спинлоками, и не назовёшь его SpinLock
Указатель обычно сводится к вгрузке аж 1 регистра (базы) константой (адресом), от которого потом и пляшут. В лучшем случае - круть типа LTO еще потом допрет, что вон там и вон там уже похожее было, так что вместо кодирования всего адреса закодирует только смещение в команде. В каком месте может оверхед возникнуть? Это ж примитивные регистровые операции в современных процессорах. Можно даже прямо относительно PC (IP, ...) кодировать на нормальных процах с относительной адресацией, ARM такое очень любят. Уродцы типа x86-32 не в счет, ими уже почти никто не пользуется.Там и так эффективность запредельная, LZ4 даже на чистом асме народ побить не смог.
Оверхед появляется на оптимизируемом коде с алиасингом, см сишный restrictВ Rust все ссылки по умолчанию restrict, но на деле их можно оптимизировать ещё сильнее, т.к у Rust правила алиасинга более строгие чем можно выразить в C
Садись, два
Полная чушь. Да, на расте можно писать как на си, но тогда он от си ничем не отличается. На сейф расте оверхед есть и он очень заметный.
ооооооооооооо даааааааааааааааааааааааауволен по причине некомпетентности, гуляй вася
Нужно. А то ядро почти не течёт.
>Благодаря этому инструменту выявятся те участки кода, которые нужно переписать на раст.Но зачем? Раз уж выявили, то можно существующих код на C подправить.
Да это просто влажные мечты растомана. Проходим мимо
> Но зачем? Раз уж выявили, то можно существующих код на C подправить.тоже логично
Нет не выявляются.
> Благодаря этому инструменту выявятся те участки кода, которые нужно переписать на раст.Пофиксить их на си будет сильно проще. А так растишки свой redox уже который там год переписыват. Но пока вроде ни 1 живого дева юзающего свое недоразумение для хотя-бы разработки ОС так и нет?
Ты не так остёр, как думаешь.Поздно пить смузи, когда продакшн упал. И удачи с исправлением в исходниках и слел6ующим деплоем.
что самое интересное, его плюсуют какие-то смузи-фанбои, что говорит о том, насколько интеллектуально развиты 95% местной аудитории
Так смузи-фанбои они же наоборот, за Rust топят.
> что самое интересное, его плюсуют какие-то смузи-фанбои, что говорит о том, насколько интеллектуально развиты 95% местной аудиторииСам и плюсует - делов-то, запустить скрипт трехстрочник.
> Всё, Раст больше не нужен?Fracta1L теперь не нужен.
(Ну, он и раньше был не нужен, но теперь за него вообще никаких аргументов не осталось)
Безопасных языков еще полно, можно за любой топить хоть за zig.
> Безопасных языков еще полно, можно за любой топить хоть за zig.Я топил за zig 8 лет назад, теперь я топлю за си, как за самый безопасный (в сравнении с теми же плюсами или даже джавой).
Языку zig 5 лет, а топил ты за него когда его не было. Завязывай уже с тем что ты там делаешь.
И что такого? Я оценил аргументы автора ещё когда он только разрабатывался. Но, в конечном счёте, пришлось признать, что си при грамотном подходе намного лучше альтернатив.
Для си статический анализ и инструментацию более-менее нарулили. А типовые проблемы - хотя-бы уже известны. А когда все обмазано новыми кульными фичами, там вообще поди угадай что сломается. К тому же растаманы шагу ступить без unsafe не могут, особенно в системщине, а так arian 5 даже и на ada безопасной расфигачили. Ну и вообще, был прикол когда олдскульный натовский разработчик авионики дал нехилый мастеркласс хипстоте, фапавшей на contract driven. Он у них баг нашел прямо в контракте. В том алгоритме который они пытались реализовать. А, он естественно на сях без багов такое же написал в два счета. Без обмазывания контрактами.И тем не менее, то что вы не знали о своем коде и боялись спросить:
http://fastcompression.blogspot.com/2019/01/compiler-warning...Ну что, признавайтесь, шалунишки, кто смог собрать свой код на самом придирчивом уровне? :)
>Fracta1L теперь не нужен.Но, ведь, скучно без него будет :)
Так вот кусочек за кусочком пытаются из Си сделать недо-Rust :)
раст, в отличии от, делает проверки на этапе компиляции
переполнение буфера от присланного по сети кривого пакета раст тоже на этапе компиляции проверяет?
При обращении к буферу Rust автоматически сделает проверки на выход за границу. При выходе будет либо паника, либо вернется Option::None, зависит как обращаться. Если эти проверки гарантированно не нужны, их выкинет оптимизатор. Для чтения данных применяются методы, которые тоже проверяют границы переданного им буфера, и не выходят за границу. (Слайсы в Rust содержат не только голый указатель, но и длину).Я не работал с голыми пакетами, но если объясните подробнее, как при кривом пакете происходит переполнение буфера, буду благодарен.
Так нет оверхеда, или есть автоматические проверки на выход за границу?
> Так нет оверхеда, или есть автоматические проверки на выход за границу?Эти проверки и в Си по хорошему надо делать, поэтому никакого оверхеда, только автоматизация. Но если вотпрямкапецкакнадо, есть unsafe-метод.
Например, кривой пакет состоит из заголовка плавающего размера и тела. Например, в заголовке, по лучшим традициям Microsoft (у них часто применялся такой подход) в самом начале есть длина заголовка, на основании которого можно вычислить, где начинается тело и размер самого тела пакета. Ну и вот, вдруг, например размер заголовка кто-то сформировал не 10, а 100. Соответственно при разборе такого пакета можно вылететь за буфер на 90 байт, если взаимно не контролировать все эти длины и между собой и с общей длиной пакета.
> Например, кривой пакет состоит из заголовка плавающего размера и тела. Например, в
> заголовке, по лучшим традициям Microsoft (у них часто применялся такой
> подход) в самом начале есть длина заголовка, на основании которого можно
> вычислить, где начинается тело и размер самого тела пакета. Ну и
> вот, вдруг, например размер заголовка кто-то сформировал не 10, а 100.
> Соответственно при разборе такого пакета можно вылететь за буфер на 90
> байт, если взаимно не контролировать все эти длины и между собой
> и с общей длиной пакета.Пакет с такой неверной длиной считается криво, но без вылетов за границу.
Если читать стандартными методами, то будет считано ровно под размер выделенного буфера. Ну или можно читать до конца, но только в расширяемый вектор. Это, конечно, не фича языка, просто в стандартной библиотеке есть вот такая готовая абстракция
https://doc.rust-lang.org/std/io/trait.Read.html
> Это, конечно, не фича языка, просто в стандартной библиотеке есть вот
> такая готовая абстракцияОсобенно интересно будет когда ты попробуешь все это в кернел моде провернуть. А хочешь прикол? Нет, никто в здравом уме и твердой памяти в ядро даже libc не засунул. Как максимум, для очень сильно нагруженных сисколов у них есть забавный хак с vDSO, когда ядро :) подпихивает типа-либу в адреса процесса. Но вот у самого по себе ядра стандартного сишного рантайма, внезапно, нет.
Более того - окружение в котором работает кернел и допущения о том что там и как здорово отличаются от "апликушных" подходов и либ. И на это были хорошие причины. Например фундаментально разная цена сбоев. Если у вас out of memory в программе, ну, хрен с ней с программой. А вот если это уже с ядром - ну, допустим, та абстракция не сможет отрастить буфер. Что будет дальше? Жоский кернелпаник с обрушением ВСЕЙ СИСТЕМЫ? А такая система будет кому-то нужна вообще?
> переполнение буфера от присланного по сети кривого пакета раст тоже на этапе
> компиляции проверяет?Пинание погроммиста использовать итератор, если он не хочет по умолчанию получить баундчек в рантайме, происходит на этапе компиляции.
Ну так и в сишке можно массив гарантированно обойти без промаха и проверок - макрос тип FOR(list, pointer, type) юзаешь и всё.
Кто-то говорил, что нельзя? А почему все не юзают? А говорит ли об этом компилятор? А почему мне язык не даст по рукам, если я использую небезопасную версию, если безопасная версия не имеет штрафа по перформансу?
> А говорит ли об этом компилятор?Так это ж не встроено в язык.
> А почему мне язык не даст по рукам, если я использую небезопасную версию
> Такова иделогия языка, что он ничего не навязывает. Впрочем компилятор делает проверки и выводит предупреждения в подозрительных случаях. В случае, когда цена ошибки - человеческая жизнь (автопром, авиация, ракетчики, медицина) - придерживаются определённых в стандарте MISRA C ограничений. Ну а если цена ошибки - вылетающая в 0.0001% случаях игра, зато можно поиметь на 20fps больше, пишут быстро, но небезоапсно.
> Такова иделогия языка, что он ничего не навязывает.Таково древнее наследие обратной совместимости и отсутствие проработанной базы (и вычислительных возможностей) теории типов 50 лет назад.
А ещё мощности ЦП подросли для выполнения смузихлёбного кода за приемлимое время и сишных библиотек на все случаи написали, которые смузихлёбы своим смузи-кодом склеивают в относительно юзабельные приложения.
> А почему все не юзают?По той же причине по которой используют неэффективные алгоритмы или пишут свой велосипед(например язык) когда есть другой.
> А говорит ли об этом компилятор?
Зависит от хотелок. Может и говорить.
> А почему мне язык не даст по рукам, если я использую небезопасную версию, если безопасная версия не имеет штрафа по перформансу?
Потому что считается что ты достаточно умный и самостоятельный и тебя не надо ограждать со всех сторон как веб-макак. По этой же причине разрешены UB - разработчики языка никак не могли знать на каком компиляторе ты собираешься компилить и под какой процессор и честно об этом заявляют. При этом настроить предупреждения о UB тебе никто не мешает.
То есть эта хитрая штука не переносима между платформами? Язык Си точно для кросплатформенной разработки?
Скажем так, по всей видимости разработчики стандарта C никак не могли повлиять на разработчиков аппаратуры (тем более тогда архитектур было побольше). Соответственно, там где не получалось найти консенсус меж разработчиками аппаратуры, и где эта самая аппаратура вела себя по-разному, там разработчики стандарта C писали - мы не знаем, как на Вашем железе, с Вашим компилятором оно будет. Это сейчас Rust-а всего одна реализация, и там его разработчики могут сказать - у нас в компиляторе оно так, и мы говорим, что оно так стандартно.
Ну то есть эта штука не кросплатформенна
> Ну то есть эта штука не кросплатформеннаНа тот момент было: "а других кроссплатформенных языков у меня для Вас нет" (с).
Мне кажется, Вы всё-таки, пытаетесь оценивать без учёта тогдашней специфики:
- тогда было больше аппаратных архитектур - тяжелее было договориться производителям аппаратуры между собой - каждый гнул свою линию и не хотел подстраиваться под других - ведь уже в аппаратуре реализовано так, и никто под компилятор переделывать железо не будет. Что говорить, что тот-же представление float/double более-менее стандартизировали в 85-то году;
- тогда было гораздо больше разработчиков компиляторов, и C в частности, причём каждый из которых скорее всего ориентировался на свою родную аппаратную архитектуру, а другие плевал с большой колокольни (даже сейчас маленькая фирма Microsoft, которая активно участвует в разработке стандартов на язык C не реализовала у себя даже C99, не говоря об более новых C11 и д.р.). На одной платформе x86 были и borland C/C++, и несколько компиляторов от Microsoft, и Intel-евский компилятор, GCC, Watcom C/C++, Digital Mars C/C++ и, небось, ещё пяток компиляторов, про которые сейчас никто даже и не вспомнит;
- железо было, по сегодняшним меркам, очень слабое и заставить какую-то из аппаратных платформ делать что-то дополнительно, только для абстрактной совместимости, которая пользователям этого железа была не нужна, ну или явно не просматривалась, было тяжеловато.С другой стороны у Rust сейчас:
- аппаратных архитектур, по сравнению со всем тем многообразием - раз два и обчёлся - кто там остались. В Rust более-менее нормально поддерживаются только 686, x86-64 и aarch64, без тестов (т.е. без гарантии того, что они хоть что-то правильно там компилируют) - arm, mips*, sparc*, power, riscv, 586.
- всего одна реализация компилятора, без всяких стандартов и необходимости хоть с кем-нибудь договариваться;
- аппаратное обеспечение гораздо мощнее, что позволяет как наворачивать сам компилятор, так и программно всех "стандартизировать" - добиваться того, что с точки зрения программы на разных аппаратных платформах она ведёт себя абсолютно одинаково - например нормализуя результат для тех платформ, которые по какой-либо причине выбиваются из строя.Так-что, имхо, сравнивать в каких условиях развивался C, а в каких Rust не совсем корректно.
> То есть эта хитрая штука не переносима между платформами? Язык Си точно
> для кросплатформенной разработки?Раст работает на всех (даже если принять работающими tier-3 платформы) платформах, поддерживаемых LLVM. Си работает на всех платформах, поддерживаемых LLVM, GCC, MSVC, ICC и многими другими компиляторами. Не адептам раста блеять про кроссплатформенность.
> То есть эта хитрая штука не переносима между платформами? Язык Си точно
> для кросплатформенной разработки?Так то си есть для сильно большего количества архитектур чем хруст. А что, хруст умеет в MSP430 или там STM8 какой? Да, они продаются. Сейчас. Миллионами.
> Ну так и в сишке можно массив гарантированно обойти без промаха и
> проверок - макрос тип FOR(list, pointer, type) юзаешь и всё.Понимаешь, алгебраические типы данных и отсутствие null - это не только модные слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки, заэнфорсив только одну - при проверке входящих данных.
На днях подобное смузихлёбство переписал по-человечески в императивном стиле, с той же в точности логикой - перформанс в ~10 раз вырос. Хотя там у компилятора был шанс выкинуть ненужное, но что-то не смог он, вопреки верованиям смузихлёбов.
>> Ну так и в сишке можно массив гарантированно обойти без промаха и
>> проверок - макрос тип FOR(list, pointer, type) юзаешь и всё.
> Понимаешь, алгебраические типы данных и отсутствие null - это не только модные
> слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора
> сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки,
> заэнфорсив только одну - при проверке входящих данных.Покажи, где ты в С нашел null, и где в switch-case по union с тегом у тебя будут лишние проверки.
> Понимаешь, алгебраические типы данных и отсутствие null - это не только модные
> слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора
> сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки,
> заэнфорсив только одну - при проверке входящих данных.Как ни странно, GCC в этом довольно неплохо преуспевает. А прикинь, он сам умеет в range check и если видит что я никогда не вызываю вон ту функцию с вон теми параметраим - выкидывает к хренам и проверки, и имплементацию этого случая.
Внезапно, в кернелмоде, с модулями и всем таким, это может сыграть дурную шутку: компилер внезапно не видит всех возможных сценариев. Как будет юзать вон тот код вот это и это - ок, а что насчет юзерского loadable module? Его видите ли совсем не было compile time :)
>> Понимаешь, алгебраические типы данных и отсутствие null - это не только модные
>> слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора
>> сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки,
>> заэнфорсив только одну - при проверке входящих данных.
> Как ни странно, GCC в этом довольно неплохо преуспевает. А прикинь, он
> сам умеет в range check и если видит что я никогда
> не вызываю вон ту функцию с вон теми параметраим - выкидывает
> к хренам и проверки, и имплементацию этого случая.А прикинь - как ни странно, для этого используются наработки "смузихлебов" по оптимизации, можешь глянуть на md или pd файлы или как выглядит RTL (хинт:
(set (reg:SI 140)
(plus:SI (reg:SI 138)
(reg:SI 139)))
да и gcc-extensions типа pure - как раз про это.> Внезапно, в кернелмоде, с модулями и всем таким, это может сыграть дурную
> шутку: компилер внезапно не видит всех возможных сценариев. Как будет юзать
> вон тот код вот это и это - ок, а что
> насчет юзерского loadable module? Его видите ли совсем не было compile time :)Вы не поверите, но эти проблемы - как раз из-за слабой (unsound) системы типов си.
Потому что вон тот вон указатель - может указывать на хрень любой длины (разработчику просто не предоставляется достаточный инструментарий для уточнения), а может быть и NULL.
> раст, в отличии от, делает проверки на этапе компиляцииА тут их железка делает. Условно халявно - она всегда это делает, просто более креативное использование paging. Хруст, кстати, без MMU тоже, видите ли, много чего не могет - так он тоже на поддержку некоторых constraints железками полагается.
Это пять! Зашел сюда специально, чтобы почитать комменты про Rust. Заголовок новости просто кричит о том, что в комментариях будут его обсуждать. )
Ну только поржать над людьми которые больше helloworld.c не видели и даже не вдупляют что такое санитайзер.
каким был тролем таким и остался. Думал возраст тебя исправит но видно нет.
ммм ядро пишут на С и Shell и других очень низких языках раст тут не нужен
> ммм ядро пишут на С и Shell и других очень низких языках раст тут не нужен
> ядро пишут на С и Shell
> Shell и других очень низких языкахЭто опеннет ...
>> ммм ядро пишут на С и Shell и других очень низких языках раст тут не нужен
>> ядро пишут на С и Shell
>> Shell и других очень низких языках
> Это опеннет ...Как минимум Rosa Tresh полностью автономна и написана баш-программистами.
> ммм ядро пишут на С и Shell и других очень низких языках раст тут не нуженНа shell там разве что кусочки системы сборки, лол.
А он был кому-то кроме фрактала (не написавшего не строчки) нужен?
Лучше бы добавили простую возможность узнавать-проверять валидные границы памяти в приложениях, существующие решения или набор непереносимых костылей или огромные библиотеки снижающие производительность
Такая возможность в C/C++ и много других языков уже давно добавлена.
if или assert, по вкусу.
Умные указатели уже миллион лет как придумали в с++. Это все равно что аналог safe в с++.
> Умные указатели уже миллион лет как придумали в с++А когда запретят писать на "тупых" указателях?
> Это все равно что аналог safe в с++
Что ты подразумеваешь под safe?
> А когда запретят писать на "тупых" указателях?Не раньше, чем из раста полностью удалят unsafe, и любой код будет safe, т.е. никогда
Ему про тупые указатели, он про раст и safe, сначала определи, что такое safe, можешь при этом не использовать слово "раст"
Это не указатели тупые, а ты тупой. В Раст есть unsafe и обычные указатели. В С++ обычные указатели это то же самое что unsafe, а есть умные указатели они как дефолтное поведение раста. Но ведь до тебя ты же растофанатик при том что на нём ни одной строчки даже не написал в силу тупости.
> Ему про тупые указателиони unsafe
> он про раст и safe, сначала определи, что такое safe
да, потому что полностью избавится от тупых указателей нельзя, даже если интерфейсы пользователя будут safe, кишки будут реализованы с unsafe. Полное выбрасывание unsafe из языка подразумевает, что на нем нельзя будет написать такие кишки.
> можешь при этом не использовать слово "раст"
за живое задел что-ли? Я не имел в виду ничего плохого в контексте раста
> сначала определи, что такое safe, можешь при этом не использовать слово "раст"У хрустиков есть кейворд такой. И что характерно, системщина без него чего-то ну совсем вот не обходится. Доходит до того что эти чудо кодеры пишут unsafe, asm, ну и какой там safety дальше наверное понятно. Черт, это уже даже статический анализ не сожрет, в asm видите ли маловато формальных деклараций намерений было.
> А когда запретят писать на "тупых" указателях?А зачем? Не надо их запрещать. Они прекрасны.
Те кто не осилил - никто не заставляет использовать. Можешь вообще без указателей.
Особенно с железками поработать. Особенно когда точный паттерн доступа к адресу важен, ога. Но хрустики напишут unsafe asm и поимеют офигенно безопасТный и охренеть какой читаемый код.А так то сие на сях делается. Если осторожно.
Что-то Debian стал много есть оперативки. Голая установка на uefi занимает 75 Мб оперативки. А ведь ещё пару лет назад 30 было. Ядро жиреет или что?
Про systemdick не забывай.
Чего минусов налепили? Проверьте сами в виртуалке хотя бы.
Хорошая попытка, но нет. Даже без гуя.
Моё ядро занимает 80-100 (понятное дело без гуя вообще без всего). Но там все эти acpi с i2c и edac и всё прочее -- если их отключить, вроде даже можно что-то сэкономить, но тогда никакого контроля над железом просто не будет.
Почему раньше всё работало и занимало 30 Мб?
Из того что я знаю, добавили различные защиты и канареечные значения на случай атак, кроме того структуры ядра теперь рандомизируются в памяти.
Если раньше все работало, то зачем ты что-то меняешь? Сиди себе на своем старье на пуле памяти в 30мб
Я хотел узнать причины, а не слушать едкие бессмысленные колкости.
Ну смотриТы не сидишь на своем старье, потому что тебя что-то не устраивало в нем, ты взял по-новее, решив свои проблемы, но расплатившись за это потреблением памяти, то есть решение проблем потребовало увеличения потребления памяти
Так яснее?
При чём здесь мой выбор новой версии? Я спросил лишь причину жора оперативки. Меня не интересует обсуждение причин выбора новой версии. Неужели это непонятно? Но раз уж такой интерес, скажу. Старые версии не имеют поддержки и исправления безопасности к ним не приходят.
>решение проблем потребовало увеличения потребления памятиНе потребовало. Проблемы как таковой нет. Раньше обновлялся и жора не было. Теперь есть. И я _просто_ хочу узнать причины.
> Старые версии не имеют поддержки и исправления безопасности к ним не приходят
> Не потребовало. Проблемы как таковой нет.Обновления безопасности - проблема? Если нет проблем, то почему тебя беспокоят обновления безопасности? С чего ты взял, что обновления безопасности не жрут память?
> Раньше обновлялся и жора не было.
Раньше было лучше, только вот проблемы безопасности не решают, а когда решают, становится хуже, зачем же они делают нам хуже?
Предлагаю тебе определится, что же все таки лучше - проблемы с безопасностью и пул в 30мб, или исправление проблем с безопаснотью
> И я _просто_ хочу узнать причины.
Ну дак тебе и отвечают - потому что в новых версиях есть исправления твоих проблем, а вдобавок еще миллиона таких же как ты
Я не вижу достаточной аргументации, лишь верчение словами, а это не ответ.
>С чего ты взял, что обновления безопасности не жрут память?А счего ты взял, что жрут? OpenBSD у меня из коробки 20 Мб ест. И это при том, что проект стремится из коробки иметь много всякого для безопасности. Так почему же Linux стал больше есть? Может быть, знаете конкретную причину, конкретные изменения, приведшие к этому? Если нет, то разговор бессмысленный.
> А счего ты взял, что жрут?Наблюдаю по ленсуку, венде и прочим живым ОС. Наращивание фич - увеличение потребления ресурсов
> OpenBSD у меня из коробки 20 Мб ест
И это единственное, что она может, запуститься и реализовать мощность моего ноутбука она не в состоянии
> И это при том, что проект стремится из коробки иметь много всякого для безопасности.
Перечисли пожалуйста, что именно, заодно напомни, когда последний раз находили в этой поделке уязвимости
> Может быть, знаете конкретную причину, конкретные изменения, приведшие к этому?Конечно знаю, это не сложно узнать, берешь и сравниваешь было/стало, разница приводит к потреблению ресурсов в том или ином виде за редким исключением
> Если нет, то разговор бессмысленный.Он, очевидно, изначально бессмысленный. Ленсук жрет память, потому что так его создатели написали, они готовы смириться с этим, потому что выигрывают в чем-то другом, если тебе это не нужно - не юзай, никто не заставляет
Не знаешь.
Прекрасно знаю
1. x86-64
2. Ряд структур стал несколько более рыхлым с годами, но это позволяет иметь меньшую нагрузку на CPU
Специалист по ИБ из вас так себе.
Ты тоже из тех, кто считает, что если в системе есть баги, то это называется "все работает"?
Нет.
Ты тоже из тех, кто считает, что бывают сколь-либо сложные системы, в которых нет багов? :)
Я из тех, кто считает, что если тебя все устраивает, то зачем что-то менять?
Ну так абсолютно правильный ответ в начале дали. Нет смысла обновляться на новое ядро и т.п., если всё устраивает :)
ну так ему и сказали - не обновляйся, но ведь он хочет "безопасность", значит его уже не все устраивает
> Чего минусов налепили? Проверьте сами в виртуалке хотя бы.Запустил armhf версию на 64 мегах без свопа. Нормально? Не быстро, конечно - дискового буфера мизер.
Отключи Huge pages и будет кушать НАМНОГО меньше. Другой вопрос, что ты будешь потом жаловаться на фрагментацию оперативной памяти.
Смотря какие huge pages. Если transparent - то ведро нормально справляется с переаллокацией. Если принудительные аллокации в софте - там да, хип на полтора байта 2 метра весит.
> Смотря какие huge pages. Если transparent - то ведро нормально справляется с
> переаллокацией. Если принудительные аллокации в софте - там да, хип на
> полтора байта 2 метра весит.Ну переключи madvise параметр у ядра и проверь, сколько будет жрать ОЗУ после перезагрузки. Потом сравнишь с умолчальным. Разница будет в несколько сот мегабайт.
> Ну переключи madvise параметр у ядра и проверь, сколько будет жрать ОЗУ
> после перезагрузки. Потом сравнишь с умолчальным. Разница будет в несколько сот
> мегабайт.Взял одну из тестовых систем с MariaDB и обвесом. Поигрался.
transparent_hugepage=never
MiB Mem : 19977.5 total, 14021.8 free, 3160.5 used, 2795.3 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 16383.6 avail Memtransparent_hugepage=madvise
MiB Mem : 19977.6 total, 14056.1 free, 3145.9 used, 2775.5 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 16280.9 avail Memtransparent_hugepage=always
MiB Mem : 19977.6 total, 13979.7 free, 3223.9 used, 2774.0 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 16210.3 avail Mem(последний бут из meminfo - большие страницы есть в принципе)
DirectMap4k: 220592 kB
DirectMap2M: 9207808 kB
DirectMap1G: 12582912 kB(количество распределённых по нулям, не нужны они софту :D)
Хотя не, про распределённые вру, total был более 0.
Раз уж за жадный до РАМы Линукс пошла пьянка, то ещё аллокатор памяти можно на какой-нибудь jemalloc поменять через LD_PRELOAD. Со старыми версиями glibc (до 2.26 вроде) особенно было актуально. Сейчас тоже смысл есть зачастую, но надо тестировать с самым "любимым" приложением. Ситуация перестала быть очень однозначной. Плюс, ряд приложений внутренне уже используют свой аллокатор памяти (FF тот же jemalloc древней версии какой-то использует).
Мне показалось - именно показалось, тестов много не делал, что в последнее время разница между malloc и jemalloc почти стёрлась.
Она значительно уменьшилась, но не исчезла. Cугубо на синтетических тестах вроде http://ithare.com/testing-memory-allocators-ptmalloc2-tcmall.../ у меня jemalloc всё ещё выигрывает у родного. Но в реальных приложениях разница в производительности уменьшилась по сути до точности измерения. Хотя, по кол-ву пожираемой памяти разница есть заметная.
С madvise даже немножко меньше выходит, потому что ядро себя слегка пооптимальнее раскладывает.
Но у меня с thp по другим причинам не сложилось, там на расщепление страниц очень большие накладные расходы, поэтому оно везде выключено.
C ним и должно меньше выходить. На десктопе разница заметнее кстати.
Ну да. Там смотрю буферы диска с thp пооптимальнее ещё разложились.
Но всё равно, на системе с 12 крупными фоновыми демонами и ещё чистым MariaDB buffer pool никакими сотнями метров близко не пахнет.
Делайте скидку на x86-64, в два раза разбухают указатели.
Плюс сам код рыхлее.
Но и модули памяти на месте не стояли, в пристойных машинах менее 4G уже не встретить, а на серверах вообще кошмарные объёмы, у меня системный SSD меньше :D
Пару лет назад у меня был всё тот же x86-64. Видимо код разрыхлили.
Не совсем код.
Взять то же ядро.
Cтруктурки повыравнивали, чтобы в кеш удобнее ложились. RCU во все поля. Куча percpu структур новых - рост числа ядер в процах породил необходимость параллелить всё, что можно. Ну и самих структурок поболе стало. В сетевом стеке только с 4.x до 5.x вагон и тележка изменений.
Никаких скидок, только рассрочка.
Т.е памяти потребляться будет ещё больше ?
Нет, физическая память под guard-страницы не выделяется.
А указатели на эти дополнительные струкуры не в физической памяти создаются?
Самое то для старых компьютеров, на которых memtest бьёт тревогу, а QEMM постоянно показывает окно "ой, у вас тут содержимое памяти повредилось". Но при этом надо как-то выживать, потому что SIMM или DIMM SDRAM уже хрен купишь.Или это не то?
Нет. Это не то. То (возможномть передать ядру список битых блоков RAM) есть с первых версий linux.
Не то, это легковесный аналог address sanitizer, чисто пытается проверять выходы за границу массивов/объектов. Для твоих нужд badram давно в ядре есть, если сбоят конкретные участки. Но, вообще говоря, контакты чисть и проверь охлаждение.И да, где это SIMM/DIMM хрен купишь? Залежи же.
полгода назад выкинул 10 планок по 64мб pc-133, до этого оно лежали на авито с полгода по 1 рубль штука.
Они тупо не нужны были людям.
> полгода назад выкинул 10 планок по 64мб pc-133, до этого оно лежали
> на авито с полгода по 1 рубль штука.Странно, они на драгмет заметно дороже идут.
> Странно, они на драгмет заметно дороже идут.Эм, даже в существенно более старых буржуйских компонентах драг.металлы отсутствуют. Точнее, если чего и присутствует, то в совсем уж следовых количествах, так что на моей памяти их никто не принимал. Неужели сейчас начали перерабатывать и такое?
Тут скорее проблема как можно быстрее мусорное ведро найти.
Может, тебе подумать, какому бы музею вычтехники всю твою коллекцию продать? На вырученны, глядишь, и один новый компуктер прикупить выгорит.
Какие только костыли не придумают, лишь бы не изучать раст
Компилятор, пусть даже раста, не может дать гарантий. Гарантии корректной работы с памятью может дать только ядро OS и процессор.
Ядро стало помойкой.
а вы видимо каждый раз глаза закрываете на ту кучу уязвимостей, связанных с переполнением буфера
Fracta1L! Ты уволен!
Почему не интегрировали готовую защиту памяти от PaX из https://grsecurity.net ?Потому что PaX имеет очень строгую защиту памяти, наличие которой у GNU/Linux многим не нравится!
А давно ли суды были с этой самой сесурити, забившей на лицензию?
Там длинная история: https://www.opennet.ru/openforum/vsluhforumID3/119728.html#31PaX патчи для защиты памяти отдельный проект, grsecurity его в себя интегрировал.
Патчи распространяются под GPL-2 и их можно включать в основное ядро.
> Там длинная история: https://www.opennet.ru/openforum/vsluhforumID3/119728.html#31При том не такая однозначная как тут лечат. Там у людей довольно специфичные подходы и приоритеты. Вплоть до того что при непонятках лучше уронить систему, на всякий... но закавывка в том что это немного непрактично для продакшна. В конце концов компьютеры ставят чтобы работать а не паниковать.
> Патчи распространяются под GPL-2 и их можно включать в основное ядро.
У основного ядра расстановка приоритетов несколько другая, а своенравный и некооперативный апстрим - таки тоже отдельная проблема.
Не всем удается без смс и просмотра рекламы его скачать. Может по-этому ?
По моему скромному мнению, это всё костыли, а проблема кроется в неудачной архитектуре процессора и его системы команд. Можете бить меня тапками или кидать в меня камни, но от своего скромного мнения, я не откажусь.
> от своего скромного мнения, я не откажусь.Да кому ты нужен со своим скромным мнением?
Проблема кроется в неудачной архитектуре человеческих мозгов, которые не заточены на 100% точные вычисления.
Как бы, и да, но наследие есть наследие, и пилить архитектуру с чистого листа, конечно, можно (если есть много денег и времени), но её внедрение будет весьма затруднительно. Так что, пока живём с x86 и наслоением новых макроинструкций. \(o_O)/
Плохому танцору вечно что-то мешает
>Подобная функциональность уже присутствовала в ядре в виде опции сборки KASAN (kernel address sanitizer, использует Address Sanitizer в современных gcc и clang) - однако позиционировалась в основном для отладочного применения.Но ведь на убунте kasan из коробки идёт, и включается опцией в строке ядра.
Ошибся, не kasan, а kaslr.
Судя по описанию, на рабочих системах такое не нужно, в эксплоитах это обойдут, а говнодрайверы броадкома и так постоянно крашатся при полном отсутствии свободных аналогов, хорошо что хоть к панике ядра это не приводит.
Если Rust такой хороший, зачем нужны подобные патчи? Шах и мат, смузихлёбы
Товарищи, как бы это дело бекпортировать хотяб на 4.19 ? Памагите !
И что это за сабатирование arm-a ? зачем 64, не хотим мы 64
Я так понимаю, "классический" arm лет через эннадцать пойдёт на выпил вместе с i?86 :)
они лишь оттягивают неминуемое переписывание на rust.есть же и другие ошибки памяти, а не только обращения к не размеченным областям..
Они доказывают ненужность rust
> неминуемое переписывание на rust
> есть же и другие ошибки памятиНу вот ты и доказал ненужность хруста.
Валгринд засунули в ядро.
Зачем?
Чтобы не ждать вечность пока работает валгринд.
> но предусмотрена настройка "panic_on_warn"А нельзя просто грохать приложение?
Так прикольнеее ^_^
Какое приложение? Это санитайзер для ядерной кучи, для памяти используемой ядром. Если там косяк, то это косяк ядра, и юзерспейс код тут ни при чём. Более того, даже если его грохнуть, то это скорее всего не поможет, потому как косячные структуры в куче ядра продолжат существовать.
Можно, panic_on_warn именно это и делает
Когда система уходит в бесконечный своп и перестаёт реагировать на операции ввода, о чём в это время думает Торвальдс, какие все кругом 3.14-до-сы?