fugahogeds更新されたよ、見に来てね!→ 機密が漏れてる?! #Bitwarden 侵害から #OpenBLAS まで 今日の #OSS たちのトピックを1本でつなぐ、紡ぐ 2026年04月24日(金) #News #Security https://www.youtube.com/watch?v=Cd6WKFaCvD4
YouTube
更新されたよ、見に来てね!→ 【ダイジェスト】機密が漏れてる?! #Bitwarden 侵害から #OpenBLAS まで 今日の #OSS たちのトピックを1本でつなぐ、紡ぐ 2026年04月24日(金) #News https://www.youtube.com/shorts/CoVqZa10q7k
【ダイジェスト】機密が漏れてる?! #Bitwarden 侵害から #OpenBLAS まで 今日の #OSS たちのトピックを1本でつなぐ、紡ぐ 2026年04月24日(金) #News
Stéphane Charette 🇨🇦Darknet/YOLO running the usual LEGO dataset on a Raspberry Pi 5 used to get 10.52 FPS. With the recent performance changes over the last few days, it is now running at 17.57 FPS on RPI 5. #Darknet #YOLO #OpenBLAS
HabrOpenBLAS/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.
Christos Argyropoulos MD, PhD, FASN 🇺🇸 0kale/acc
Christos Argyropoulos
Christos Argyropoulos MD, PhDgcc14 is reported to be problematic on building math/openblas by another user.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284425#c35
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.
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