C++ быстрее и безопаснее Rust, Yandex сделала замеры
Спойлер: C++ не быстрее и не медленнее и вообще смысл не в этом. Эта статья является продолжением славных традиций развенчания мифов крупных российских компаний о языке Rust. Предыдущая была «Go быстрее Rust, Mail.Ru Group сделала замеры».
Недавно я пытался заманить коллегу, сишника из соседнего отдела, на Тёмную сторону Rust. Но мой разговор с коллегой не задался. Потому что, цитата:
Антон Полухин является представителем России в ISO на международных заседаниях рабочей группы по стандартизации C++, автором нескольких принятых предложений к стандарту языка C++. Антон действительно крутой и авторитетный человек в вопросах по C++. Но доклад содержит несколько серьёзных фактических ошибок в отношении Rust. Давайте их разберём.
Речь идет об этом докладе с 13:00 по 22:35.
Оглавление
Миф №1. Арифметика в Rust ничуть не безопасней C++.
Для примера сравнения ассемблерного выхлопа Антон взял функцию возведения в квадрат(link:godbolt):
В самом деле, ассемблерный листинг арифметического умножения в обоих случаях выглядит одинаковым, но это только до поры до времени. Дело в том, что с точки зрения семантики языков, код делает разные вещи. Этот код определяет функции возведения числа в квадрат, но в случае Rust область определения [-2147483648, 2147483647], а в случае C++ это [-46340, 46340]. Как такое может быть? Магия?
Магические константы -46340 и 46340 — это максимальные по модулю аргументы, квадрат которых умещается в std::int32_t . Все что выше будет давать неопределенное поведение из-за signed overflow. Если не верите мне, послушайте PVS-Studio. И если вы достаточно удачливы, чтобы работать в командах, которые настроили себе CI с проверкой кода на определенное поведение, вы получите такое сообщение:
В Rust такая ситуация с неопределенным поведением в арифметике невозможна в принципе.
Давайте послушаем, что об этом думает Антон (13:58):
Я бы почитал, какие оптимизации не умеет Rust, особенно с учётом того, что в основе Rust лежит LLVM — тот же самый бэкенд, что и у Clang. Соответственно, Rust «бесплатно» получил и разделяет с C++ большую часть независящих от языка трансформаций кода и оптимизаций. И хотя в представленном примере мы и получили одинаковый ассемблер, на самом деле, это случайность. Хитрые оптимизации и наличие неопределённого поведения при переполнении знакового в языке C++ могут приводить к веселью и порой порождают такие статьи. Рассмотрим эту статью подробнее.
Дан код функции, вычисляющей полиномиальный хеш от строки с переполнением int’a:
Как подсказывает PVS-Studio, неопределенное поведение действительно не определено. Если посчитать 27752 в 3 степени, можно понять, почему хэш от двух букв считается нормально, а от трех уже с какими-то странными результатами.
Аналогичный код на Rust будет вести себя корректно(link:playground):
Выполнение этого кода отличается в Debug и Release по понятным причинам, а для унификации поведения можно воспользоваться семейством функций: wrapping*, saturating*, overflowing* и checked*.
Как видите, документированное поведение и отсутствие неопределённого поведения при переполнении знакового действительно делают жизнь легче.
Вычисление квадрата числа — это отличный пример того, как можно выстрелить себе в ногу с помощью C++ в трех строчках кода. Зато быстро и с оптимизациями. Если от обращения к неинициализированной памяти ещё можно откреститься вдумчивым взглядом, то проблема с арифметикой в том, что беда может прийти совершенно внезапно и на «голом» арифметическом коде, где ломаться на первый взгляд нечему.
Миф №2. Плюсы Rust только в анализе времени жизни объектов.
В качестве примера приводится следующий код(link:godbolt):
Здесь мы наблюдаем бесконечную рекурсию. Опять-таки код компилируется в одинаковый ассемблерный выхлоп, то есть NOP для функции bar как в C++, так и в Rust. Но это баг LLVM.
Если вывести LLVM IR кода с бесконечной рекурсией, то мы увидим(link:godbolt):
| code | |
| asm | |
| IR |
ret i32 undef — и есть ошибка, сгенерированная LLVM.
В самом LLVM бага живет с 2006 года. И это важный вопрос, ведь необходимо иметь возможность пометить бесконечные цикл или рекурсию так, чтобы LLVM не мог оптимизировать это в ноль. К счастью, есть прогресс. В LLVM 6 добавили интринсик llvm.sideeffect, а в 2019 году в rustc был добавлен флаг -Z insert-sideeffect , который добавляет llvm.sideeffect в бесконечные циклы и рекурсии. И бесконечная рекурсия становится действительно бесконечной(link:godbolt). Надеюсь, что в скором времени этот флаг перейдет и в stable rustc по умолчанию.
В C++ бесконечная рекурсия и цикл без побочных эффектов считаются неопределённым поведением, так что от этой баги LLVM страдают только Rust и C.
Итак, после того, как мы разобрались с ошибкой LLVM, давайте перейдем к главному заявлению: «его безопасность заключается только в анализе времени жизни объектов». Это заявление ложно, так как безопасное подмножество Rust защищает от ошибок, связанных с многопоточностью, гонками данных и выстрелами по памяти.
Миф №3. Вызовы функций в Rust бездумно трогают память.
Вывод ассемблера для Rust длинный, но мы разберемся в причинах такой разницы. В этом примере Антон использует флаги -ftrapv для C++ и -C overflow-checks=on для Rust, чтобы включить проверку на переполнение знаковых. При переполнении C++ прыгает на инструкцию ud2 , которая приводит к «Illegal instruction (core dumped)», а Rust прыгает на вызов функции core::panicking::panic , подготовка к которой занимает половину ассемблерного кода. В случае переполнения core::panicking::panic дает нам красивое объяснение падения:
Так откуда взялись эти «лишние» инструкции, которые трогают память? Соглашение о вызове функции x86-64 требует, чтобы стек был выравнен до 16 байт, инструкция call кладёт 8-байтовый адрес возврата на стек, что ломает выравнивание. Чтобы это исправить, компиляторы кладут всякие инструкции типа push rax. И так делает не только Rust, но и C++(link:godbolt):
И C++, и Rust сгенерировали одинаковый выхлоп ассемблера, оба добавили push rbx для выравнивания стека. Q.E.D.
Самое интересное заключается в том, что именно C++ нуждается в деоптимизации кода путём добавления аргумента -ftrapv , чтобы ловить неопределенное поведение при переполнении знаковых. Выше я уже показал, что Rust будет вести себя корректно даже без флага -C overflow-checks=on , так что можете сравнить сами(link:godbolt) стоимость корректного кода на C++, либо почитайте статью на эту тему. К тому же -ftrapv в gcc сломан с 2008 года.
Миф №4. Rust медленнее C++.
На протяжении всего доклада Антон выбирает примеры, написанные на Rust’е, которые компилируются в чуть больший ассемблер. Не только примеры выше, которые «трогают» память, но и пример на 17:30(link:godbolt):
Складывается впечатление, что весь этот анализ ассемблерного выхлопа был нужен лишь для того, чтобы сказать, что больше асма → медленнее язык.
В 2019 на конференции CppCon был интересный доклад There Are No Zero-cost Abstractions от Chandler Carruth. Вот он там на 17:30 сильно страдает из-за того, что std::unique_ptr стоит дороже сырых указателей (link:godbolt). И чтобы хоть как-то приблизиться к ассемблерному выхлопу кода на сырых указателях ему приходится добавлять noexcept , rvalue ссылки, и использовать std::move . А на Rust всё будет работать без дополнительных усилий. Давайте сравним два кода и ассемблер. В примере на Rust мне пришлось дополнительно извратиться с extern «Rust» и unsafe , чтобы компилятор не заинлайнил вызовы (link:godbolt):
При меньших трудозатратах Rust генерирует меньше ассемблера. И не нужны подсказки компилятору в виде noexcept , rvalue ссылок и std::move . В сравнениях языков нужны нормальные бенчмарки. Нельзя вытащить понравившийся пример, и утвержать, что один язык медленнее другого.
В декабре 2019 Rust превосходил по производительности C++ согласно результатам Benchmarks Game. С тех пор C++ немного укрепил свои позиции. Но на таких синтетических бенчмарках языки будут раз за разом обходить друг друга. Я бы не отказался посмотреть нормальные бенчмарки.
Миф №5. C → С++ — noop, C → Rust — PAIN.
Вот тут Антон смешал в одну кучу объявление сишных функций и их последующее использование.
Действительно, объявление сишных функций в Rust требует либо их ручного объявления, либо автоматической генерации, потому что это разные языки программирования. Подробнее можно прочитать в моей статье про бота для Starcraft, либо посмотреть на пример генерации этих оберток.
К счастью, у языка Rust есть пакетный менеджер cargo, который позволяет один раз сгенерировать объявления и поделиться ими со всем миром. Как вы понимаете, люди делятся не только сырыми объявлениями, но и безопасными и идиоматичными обёртками. На 2020 год в реестре пакетов crates.io находится около 40 000 крейтов.
Ну а само использование сишной библиотеки занимает буквально одну строчку в вашем конфиге:
Всю работу по компиляции и линковке с учетом версий зависимостей cargo выполнит автоматически. Пример с flate2 примечателен тем, что в начале своего существования этот крейт использовал сишную библиотеку miniz, написанную на C, но со временем сообщество переписало сишный код на Rust. И flate2 стал работать быстрее.
Миф №6. unsafe отключает все проверки Rust.
Данный пункт является продолжением темы про интеграцию сишных библиотек в Rust’овый код.
Увы, мнение об отключении всех проверок в unsafe — это типичное заблуждение, потому что в документации к языку Rust сказано, что unsafe позволяет:
- Разыменовывать сырой указатель;
- Вызывать и объявлять unsafe функции;
- Читать или измененять статическую изменяемую переменную;
- Реализовывать и объявлять unsafe типаж;
- Получать доступ к полям union .
Ни о каких отключениях всех проверок Rust здесь и речи не идет. Если у вас ошибка с lifetime-ами, то просто добавление unsafe не поможет коду скомпилироваться. Внутри этого блока компилятор продолжает проверять код на соответствие системы типов, отслеживать время жизни переменных, корректность на потокобезопасность и многое-многое другое. Подробнее можно прочитать в статье You can’t «turn off the borrow checker» in Rust.
К unsafe не стоит относиться как «я делаю, что хочу». Это указание компилятору, что вы берете на себя ответственность за вполне конкретный набор инвариантов, которые компилятор самостоятельно проверить не может. Например, разыменование сырого указателя. Это мы с вами знаем, что сишный malloc возвращает NULL или указатель на аллоцированный кусок неинициализированной памяти, а компилятор Rust об этой семантике ничего не знает. Поэтому для работы с сырым указателем, который вернул, к примеру, malloc , вы должны сказать компилятору: «я знаю, что делаю; я проверил, там не нулл, память правильно выравнена для этого типа данных». Вы берете на себя ответственность за этот указатель в блоке unsafe .
Миф №7. Rust не поможет с сишными библиотеками.
По статистике Microsoft, 70% уязвимостей связаны с нарушениями безопасности доступа к памяти и с другими классами ошибок, которые Rust предотвращает ещё на этапе компиляции. Это ошибки, которые физически невозможно совершить в безопасном подмножестве Rust.
С другой стороны, существует и unsafe подмножество Rust, которое позволяет разыменовывать сырые указатели, вызывать сишные функции… и прочие небезопасные вещи, которые могут сломать вашу программу, если ими пользоваться неправильно. В общем, именно то, что делает Rust системным языком программирования.
И, казалось бы, можно поймать себя на мысли, что если в Rust и в C++ надо следить за корректностью вызовов сишных функций, то Rust ничуть не выигрывает. Но особенностью Rust является возможность разграничения кода на безопасный и потенциально опасный с последующей инкапсуляцией последнего. А если на текущем уровне гарантировать корректность семантики не удаётся, то unsafe надо делегировать вызывающему коду.
На практике делегация unsafe наверх выглядит вот так:
slice::get_unchecked — это стандартная unsafe функция, которая получает элемент по индексу без проверок индекса на выход за границы. Так как в нашей функции get_elem_by_index мы тоже не проверяем индекс, а передаем его как есть, то наша функция потенциально опасна. И любое обращение к такой функции требует явного указания unsafe (link:playground):
Если вы передадите индекс, выходящий за границы, то получите обращение к неинициализированной области памяти. И сделать вы это сможете только в unsafe .
Тем не менее, с помощью этой unsafe функции мы можем построить безопасную версию(link:playground):
И эта безопасная версия никогда не выстрелит по памяти, какие бы аргументы вы туда не передали. Если что, я не призываю вас писать подобный код на Rust (есть функция slice::get ), я показываю, как можно перейти из unsafe подмножества Rust в безопасное подмножество с сохранением гарантий безопасности. На месте нашей unchecked_get_elem_by_index могла быть аналогичная функция, написанная на C.
Благодаря межъязыковой LTO вызов сишной функции может быть абсолютно бесплатен:
| C | |
| Rust | |
| asm |
Я выложил проект с флагами компилятора на гитхаб. Результирующий выхлоп ассемблера аналогичен коду, написанному на чистом C(link:godbolt), но имеет гарантии кода, написанного на Rust.
Миф №8. Безопасность Rust не доказана.
В 2018 году доказали, что система типов Rust, механизмы заимствования, владения, времён жизни и многопоточности корректны. Так же было доказано, что если мы используем семантически правильный код из библиотек внутри unsafe и смешаем это с синтаксически правильным safe кодом, мы получим семантически правильный код, который не позволяет стрелять по памяти или делать гонки данных.
Из этого следует, что если вы подключаете и используете крейт(библиотеку), которая содержит unsafe, но предоставляет правильные безопасные обертки, то ваш код от этого не станет небезопасным.
В качестве практического применения своей модели авторы доказали корректность некоторых примитивов стандартной библиотеки, включая Mutex, RwLock, thread::spawn. А они используют сишные функции. Таким образом, в Rust невозможно случайно расшарить переменную между потоков без примитивов синхронизации; а, используя Mutex из стандартной библиотеки, доступ к переменной всегда будет корректен, несмотря на то, что их реализация опирается на сишные функции. Круто? Круто.
Заключение
Объективно обсуждать относительные преимущества того или иного языка сложно, особенно если вам сильно нравится один язык и не нравится другой. Весьма часто новый апологет очередного «новоявленного языка-убийцы C++» делает громкие заявления, не разобравшись толком с C++, за что ожидаемо получает по рукам.
Однако от признанных экспертов я ожидаю взвешенного освещения ситуации, которое, как минимум, не содержит грубых фактических ошибок.
Большое спасибо Дмитрию Кашицыну и Алексею Кладову за ревью статьи.
в rustc был добавлен. И бесконечная рекурсия становится действительно бесконечной(link:godbolt). Надеюсь, что в скором времени этот флаг перейдет и в stable rustc по умолчанию.
Си — это сэнсэй черепашек-ниндзя
Си — это императивный язык программирования общего назначения и один из старейших (создаваться он начал в 1969 году). Его отцом-основателем является Деннис Ритчи. В 1989 году Американский национальный институт стандартов и Международная организация по стандартизации разработали новые консенсусные стандарты для Си. Будучи простым, низкоуровневым языком программирования, который работает на различных платформах, он и сейчас остаётся универсальным и по-прежнему широко используется.
Бытовые приборы, такие как микроволновые печи, стиральные машины и цифровые фотокамеры, с каждым днём становятся всё более совершенными. Об этом свидетельствует наличие в них микропроцессора, операционной системы и программного обеспечения. Эти программы должны работать эффективно, задействуя при этом небольшой объём памяти. Неудивительно, что они пишутся на Си.
Основные части популярных операционных систем, таких как Windows, UNIX и Linux, написаны на Си. Ведь даже сегодня по производительности языку Си нет равных, хотя это не означает, что так будет всегда. Кроме того, если требуется расширить операционную систему для работы с новыми устройствами, нужны программы-драйверы устройств. И эти программы тоже пишутся исключительно на Си.
Язык Си оказывает огромное влияние на сферу информационных технологий и по-прежнему играет здесь жизненно важную роль.
Rust — потенциальный конкурент во всех областях
Rust — это мультипарадигмальный язык программирования с упором на производительность и безопасность, и особенно на безопасный параллелизм. С точки зрения синтаксиса Rust аналогичен языку C++. А что касается безопасности при работе с памятью, Rust обходится без сборки мусора: вместо неё здесь система проверки заимствования.
Разработка Rust была начата Грейдоном Хором в сообществе Mozilla Research.
В Rust основной акцент сделан на:
Безопасность при работе с памятью
Основное преимущество Rust: он гарантирует, что во время компиляции приложение будет избавлено от разыменования нулевых или висячих указателей. К тому же, Rust затрудняет возникновение утечки памяти.
Производительность
В языке Rust сборщик мусора не предусмотрен. Rust узнаёт о том, когда переменная выходит из области видимости или когда её время жизни заканчивается, во время компиляции. После чего вводит соответствующие команды ассемблера/LLVM для освобождения памяти. Это повышает производительность во время выполнения.
Многопоточность
Потоки в Rust автоматически «изолируются» друг от друга благодаря такому понятию, как владение. Запись происходит, только когда поток имеет изменяемый доступ — либо владея данными, либо имея изменяемое заимствование. В обоих случаях поток гарантированно будет единственным, имеющим доступ в любой момент времени.
Поддержка Web Assembly
Web Assembly помогает выполнять алгоритмы с большим объёмом вычислений в браузере, на встроенных устройствах или где-либо ещё. Он запускается со скоростью машинного кода. Rust компилируется в Web Assembly с целью быстрого и надежного выполнения.
Сравнение скорости Си и Rust
Методология
Для сравнения скорости этих двух языков применятся такой подход: пишутся самые популярные алгоритмы сортировки, которые запускаются для различных диапазонов элементов. При этом оценивается, у какого языка сортировка элементов заняла больше времени.
Используются следующие алгоритмы сортировки:
Колонки со сложностью в худшем случае (Worst Case) позволяют примерно определить, какой метод сортировки будет выполняться хуже всех.
Для сортировки пузырьком сложность в худшем случае составит O(N²). Это будет худшее выполнение по сравнению с другими методами сортировки. Будет сгенерирована итоговая матрица, которая поможет определить временную сложность в худшем случае. Для этого надо сравнить время, необходимое для сортировки элементов.
Таким образом пишутся все пять алгоритмов на Си и на Rust. Для цели ввода используется массив целых чисел, заполняемый случайными числами с помощью функции-генератора случайных чисел rand() на Си и rand::Rng на Rust. Этот массив задаётся в качестве входных данных для алгоритмов сортировки, а выходные данные записываются в матрицу. Дальше тестируется производительность алгоритмов для трёх диапазонов: 1000, 10 000 и 100 000 элементов.
Такой набор значений запускается в течение 100 итераций, а для генерации матрицы выходных данных выполняется усреднение.
Конфигурация для сравнения производительности
Конфигурация системы, в которой был запущен и выполнен подсчёт значений:
ОС: macOS Catalina.
Машина: MacBook Pro (16 дюймов, 2019 года).
Процессор: 2,3 ГГц 8-ядерный Intel Core i9.
Память: 16 Гб 2667 МГц DDR4.
Версия clang 12.0.0 (флаг оптимизации -O3).
rustc 1.45.2 (флаг оптимизации — release).
Статистика производительности
Ниже приводятся сгенерированные матрицы выходных данных:
Матрица выходных данных показывает примерно равные результаты. Для каждого метода сортировки и каждого диапазона входных массивов в каких-то случаях Rust работает лучше, а в каких-то случаях лучше работает Си. В нижних диапазонах (1000 элементов), за исключением сортировки вставками, Rust работает лучше. В диапазоне 10 000 элементов Cи работает лучше во всех методах сортировки.
Гистограммы тоже показывают, что результаты почти одинаковы во всех случаях.
Можете попробовать, что получится на вашем компьютере.
Вот ссылка на Github проекта.
Заключение
Сложно сказать, какой язык быстрее, потому что это зависит от конкретного случая. Но Rust может составить конкуренцию в скорости языку Cи: он быстрее, чем многие другие популярные языки, такие как Java и Python. Помимо скорости, в Rust акцент сделан на таких функциональных возможностях, как безопасная работа с памятью и параллелизм. А кроме того, у него открытый исходный код, так что Rust используют для создания самых разнообразных программных продуктов, например игровых движков, операционных систем, файловых систем, браузерных компонентов, а также машин для моделирования виртуальной реальности. Так что в ближайшее время Rust наверняка будет уже везде.
rust vs c performance
I wanted to learn a bit about rust tasks, so I did a monte carlo computation of PI. Now my puzzle is why the single-threaded C version is 4 times faster than the 4-way threaded Rust version. Clearly I am doing something wrong, or my mental performance model is way off.
Here’s the C version:
The Rust version was not a line-by-line port:
Build and time the C version:
Build and time the Rust version:
2 Answers 2
The bottleneck, as Dogbert observed, was the random number generator. Here’s one that is fast and seeded differently on each thread
Meaningful benchmarks are a tricky thing, because you have all kinds of optimization options, etc. Also, the structure of the code can have a huge impact.
Comparing C and Rust is a little like comparing apples and oranges. We typically use compute-intensive algorithms like the one you dispicit above, but the real world can throw you a curve.
Having said that, in general, Rust can and does approach the peformance of C and C++, and most likey can do better on concurrency tasks in general.
Take a look at the benchmarks here:
I chose the Rust vs. C Clang benchmark comparasion, because both rely on the underlying LLVM.
On the other hand, a comparasion with C gcc yields different results:
And guess what? Rust still comes out ahead!
I entreat you to explore the Benchmark Game site in more detail. There are some cases where C will edge out Rust in some instances.
In general, when you are creating a real-world solution, you want to do performance benchmarks for your specific cases. Always do this, because you will often be surprised by the results. Never assume.
I think that too many times, benchmarks are used to forward the «my language is better than your langage» style of rwars. But as one who have used over 20 computer languages throughout his longish career, I always say that it is a matter of the best tool for the job.