OpenBLAS/gemm отстаёт на RISC-V

В ходе недавних исследований мы выполнили комплексное тестирование производительности математической библиотеки OpenBLAS на платформе RISC‑V и выявили существенную разницу в скорости выполнения ключевой операции матричного умножения cblas_sgemm по сравнению с архитектурой x86 — производительность оказалась значительно ниже. cblas_sgemm — функция для умножения матриц, состоящих из 32-разрядных вещественных чисел. Хотелось бы обратить внимание на то, что функция матричного умножения gemm, соответствующая стандартам BLAS, используется во многих библиотеках и алгоритмах. А OpenBLAS — одна из самых популярных реализаций стандарта BLAS с оптимизацией под различные платформы. Так на x86_64 OpenBlas получает производительность примерно 80–90% от теоретического максимума процессора. А на Risc‑v примерно 20–25%. Также была рассмотрена самостоятельно реализованная функция перемножения матриц mini‑gemm по алгоритму описанному в статье . При этом наша реализация получает производительность 30–35% от максимума. Из чего встает два вопроса: почему на RISC‑V не получили 80%, как на x86_64 и как так вышло, что наша реализация обогнала OpenBLAS.

https://habr.com/ru/articles/902442/

#openblas #gemm #riscv #производительность

gcc14 is reported to be problematic on building math/openblas by another user.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284425#c35

#FreeBSD #OpenBLAS #gcc14

Determined actual leaf ports (non meta port) depending on using ports-mgmt/pkg_tree, try starting up gimp, kdenlive went fine. xsane crashed but in epsonscan2 part which does not depend on openblas. starting up epsonscan2 (not depending on openblas) directly caused crash with SiGILL, so maybe openblas built with gcc12/gfortran12 seems to be fine.

#FreeBSD #OpenBLAS #gcc12

For anyone struggling from build failure of math/openblas:
Try setting "USE_GCC= 12" for math/openblas like below in /etc/make.conf.
Not yet tested the resulting package runs OK with its consumers, as the build for it just finished sanely but builds for a plenty of ports are still ongoing, thus, prevent me from trying.

.if ${.CURDIR:M/usr/ports/math/openblas}
USE_GCC= 12
.endif

#FreeBSD #OpenBLAS

No fail, no gain: как мы исправили более миллиона тестов, проверяя оптимизацию библиотеки OpenBLAS под RISC-V

Открытая архитектура RISC-V активно развивается: в стандарт добавляются новые расширения и инструкции, разрабатываются новые ядра и SoC. Поскольку многие компании видят перспективы архитектуры и готовы использовать ее в продакшене, создается программный стек для высокопроизводительных вычислений — RISC-V HPC (High Performance Computing). Прогресс сопровождает формирование нового тренда — OpenHPC. Он заключается в технологической независимости от решений коммерческих компаний. Причем это относится не только к ПО, но и к железу. Чтобы концепция OpenHPC реализовывалась быстрее, нужно, чтобы к инициативе присоединилось как можно больше компаний, помогающих в развитии экосистемы решений для RISC-V HPC. Меня зовут Андрей Соколов, я инженер-программист в компании YADRO. В R&D-команде мы поставили перед собой задачу: изучить, как можно поддержать архитектуру RISC-V со стороны библиотек линейной алгебры BLAS и LAPACK. Тестирование одной из open source-библиотек привело нас к интересным открытиям, о которых я расскажу под катом. Результаты тестов

https://habr.com/ru/companies/yadro/articles/821715/

#openblas #blas #lapack #линейная_алгебра #библиотеки #оптимизация #riscv

Первый взгляд на производительность CPU реализации floating-point GEMM на языке Mojo

Сравниваем производительность реализаций floating-point GEMM из OpenBLAS, Eigen и MKl с реализацией на новом языке программирования Mojo.

https://habr.com/ru/articles/783138/

#mojo #gemm #modular #openblas #eigen #mkl