HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
OpenMathLib
OpenBLAS
C2012–2026
OpenMathLib / OpenBLAS

OpenBLAS

OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.

Libraries & SDKs
Explore on GitHubRead Hacker News discussions
24Distinct people
28Mentions
0Explicit recommenders
7.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year28 dated mentions

Observed mentions: 2012-05-11 17:05:11 UTC to 2026-08-20 13:55:09 UTC.

02462012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC202
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC101
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC624
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

28 sources
steppi·Apr 1, 2024
The Fortran implementation is just a reference implementation. The goal of reference BLAS [0] is to provide relatively simple and easy to understand implementations which demonstrate the interface and are intended to give correct results to test against. Perhaps an exceptional Fortran compiler which doesn't yet exist could generate code which rivals hand (or automatically) tuned optimized BLAS libraries like OpenBLAS [1], MKL [2], ATLAS [3], and those based on BLIS [4], but in practice this is not observed. Justine observed that the threading model for LLaMA makes it impractical to integrate one of these optimized BLAS libraries, so she wrote her own hand-tuned implementations following the same principles they use. [0] https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra... [1] https://github.com/OpenMathLib/OpenBLAS [2] https://
Read the rest
www.intel.com/content/www/us/en/developer/tools/onea... [3] https://en.wikipedia.org/wiki/Automatically_Tuned_Linear_Alg... [4]https://en.wikipedia.org/wiki/BLIS_(software)
In LLaMA now goes faster on CPUs
steppi·Jun 1, 2023
Yeah. I'm going to be helping to work on expanding CI for OpenBLAS and have been diving into this stuff lately. See the discussion in this closed OpenBLAS issue gh-1968 [0] for instance. OpenBLAS’s Skylake kernels do rely heavily on intrinsics [1] for compilers that support them, but there's a wide range of architectures to support, and when hand-tuned assembly kernels work better, that's what are used. For example, [2]. [0] https://github.com/xianyi/OpenBLAS/issues/1968 [1] https://github.com/xianyi/OpenBLAS/blob/develop/kernel/x86_6... [2] https://github.com/xianyi/OpenBLAS/blob/23693f09a26ffd8b60eb...
In Learn x86-64 assembly by writing a GUI from scratch (2020)
GrayShade·May 29, 2022
> Since the author no longer has the /proc/cpuinfo, I cannot say anything for sure. If the "fma4" flag was still there, it's a VM misconfiguration. If not, the software was only looking for the model number and not the flags, which is arguably a bug. I touched on this in the article. I don't think Linux actually shows an fma4 CPU flag (it didn't on that VM), but a test program said it didn't support fma4. The OpenBLAS developers don't seem interested in fixing it [0], since it's unlikely to happen outside of misconfigured VMs. My suspicion is that the server actually had an EPYC CPU, but the hypervisor was configured to say Opteron. [0]: https://github.com/xianyi/OpenBLAS/issues/3638
In Debugging a mysterious Python crash
pabs3·Mar 7, 2022
> Russian companies adding great features to GPL software and not sharing them. I suspect that is already happening. For example Astra Linux is a Debian derivative but their developers don't appear to be active within Debian. The other thing is that some FOSS may remove support for Russia in some way. A font removed characters only used in Russian/Belarusian. Qt are blocking downloads from Russia/Belarus. OpenBLAS are considering removing support for Russian Elbrus processors. https://github.com/hikikomori82/osifont/issues/11 https://lists.qt-project.org/pipermail/development/2022-Marc... https://github.com/xianyi/OpenBLAS/issues/3551 https://www.phoronix.com/scan.php?page=news_item&px=OpenBLAS... So the non-shared forks of FOSS are likely to be inevitable.
In Russia to legalize software piracy
albertzeyer·Feb 28, 2022
We had the case that some library we were using (OpenBLAS) used pthread_atfork. Unfortunately, the atfork handler behaved buggy in certain situations involving multiple threads and caused a crash. This was annoying because we basically did not need fork at all but just fork+exec (for various other libraries spawning sub processes), where those atfork handlers would not be relevant. Our solution was to override pthread_atfork to ignore any functions, and in case this is not enough, also fork itself to just directly do the syscall without calling the atfork handlers. https://github.com/tensorflow/tensorflow/issues/13802 https://github.com/xianyi/OpenBLAS/issues/240 https://trac.sagemath.org/ticket/22021 https://bugs.python.org/issue31814 https://stackoverflow.com/questions/46845496/ld-preload-and-... https://stackoverflow.com/questions/4681
Read the rest
0597/forkexec-withou...
In Fork() is evil; vfork() is goodness; afork() would be better; clone() is stupid
homerowilson·Nov 22, 2021
I used OpenBLAS on my cheap last-generation AMD Ryzen 7 4700U laptop like so: git clone https://github.com/xianyi/OpenBLAS && cd OpenBLAS && make PREFIX=/opt/openblas install && curl https://jott.live/code/blas_test.cc | sed -n "/<code>/,/code>/p" | tail -n +2 | head -n -1 > blas_test.cpp inspect blas_test.cpp file, and then... g++ -I/opt/openblas/include/ blas_test.cc -lopenblas -std=c++11 -O3 -L/opt/openblas/lib/ -o blas_test && ./blas_test 512 512 512 100 100 and got a peak of about 192 gflops, averaging closer to 180. So yeah, the M1 is > 6x faster in this simple single-precision matrix test.
In Benchmarking the Apple M1 Max
microtonal·Sep 1, 2020
I benchmarked some of my large transformer networks the last few days and MKL is still 50% faster than OpenBLAS. What's even worse in real-world applications is that OpenBLAS misbehaves when an application uses threads. This is also described in the OpenBLAS FAQ: If your application is already multi-threaded, it will conflict with OpenBLAS multi-threading. Thus, you must set OpenBLAS to use single thread as following. https://github.com/xianyi/OpenBLAS/wiki/faq#multi-threaded
In Intel MKL on AMD Zen

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.