Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
Вопрос, а зачем ручная векторизация в коде на Rust? Разве у вас компилятор и LLVM-бекенд не проводят её автоматически или именно для вашего кода не удалось добиться устойчивой векторизации компилятором? Мне как шарписту из той же сферы статья очень понравилась, но я в уме проецировал всё описанное на гипотетический аналог на C#, в котором векторизация по факту только ручная и нам ей приходится заниматься регулярно, чтобы достичь того же эффекта, который на Rust/C++ обеспечивается компилятором (как я это себе представлял).
Спасибо за вопрос!
LLVM умеет в автовекторизацию, и в простых кейсах компилятор работает на все 100 в этом плане. Но мне этого оказалось недостаточно по двум причинам.
Первая и основная: вычисления идут с кольцевыми буферами и окнами, а не с линейными массивами. Из-за такого доступа компилятор зачастую сложнее безопасно применить векторизацию без проверки зависимостей, альясов и wrap around’ов.
Вторая: Некотырые ядра содержат сразу несколько accumulation chain’ов, к примеру LSMA, несколько редукций на проход. Такие вещи LLVM у меня не распознавал. И от простого рефакторинга cargo asm выдавал совершенно другой код.
Вышел неплохой низкоуровневый перформанс инжиниринг
Компиляторы консервативно не делают векторизацию операций с плавающей точкой, так-как это может сломать устойчивые численные алгоритмы. Поэтому нужно вручную подсказывать/указывать где можно делать автовекторизацию.
Но пока в Rust нет хорошего(по мнению большинства) способа это делать. Поэтому пока пляшем вокруг std::SIMD, std::intrinsic и дизайном кода, который склоняет к векторизации.
Простите, но напомнило - "его лук кутюр, но без этих кутюр прайсиз, его костюмы - смотря какой фэбрик, смотря сколько дитейлз".
И как на ламбу уже заработали роботом или нет ?
А зачем числа с плавающей точкой? нельзя обойтись целочисленной математикой, если количество цифр после запятой известно из протокола биржи например.
Инт математика быстро превратится в ручной fixed point, с масштабом, округлениями, переполнением и кучей других контрактов. По сути это уже своя реализация плавающей запятой. Если и использовать такой подход, то только для цены/количества. Но для скользящих и регрессионных формул по моему мнению f64 безопаснее и проще
Любой человек, который хоть немного занимался производительностью, это знает. Главная проблема не в отсутствии знаний про uops, а в том, что большинство проектов вообще не имеют нормальных измерений
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Четыре f64 за одну инструкцию не делают вас быстрыми: как я векторизовал торговый движок на Rust и словил CI на лжи