4 ms·
You bring up a good point, but I think the takeaway is that you need to be thoughtful about the process, not necessarily that one way or the other is always rig
by anderspitman 7y ago
You bring up a good point, but I think the takeaway is that you need to be thoughtful about the process, not necessarily that one way or the other is always right.
How often are breaking changes introduced to the APIs of OpenBLAS or LAPACK? I would guess approximately never (I could be wrong though. I'm actually surprised and a bit disturbed how much activity the GitHub repos are still getting).
Beyond that, how much of the API do you need, or are likely to need in the future? Why not implement that matrix multiplication yourself to start, but abstracted in a way where you can drop in OpenBLAS in the future? You can even copy their API if you don't want to abstract, and include a bit of profiling to warn you if it suddenly gets very slow on a certain platform.
In my experience the chances are good you'll never need that last 20%.
- robmccoll 7y agoThat activity is probably grad students and post-docs looking to publish any overall optimizations or implementations for exotic architectures they can come up with.
- anderspitman 7y agoIf true; even more disturbing.
- pletnes 7y agoSome of the activities in the last decade includes significant improvements in the documentation, build and test automation. The code might have been good before, but the usability and quality of testing has improved significantly.
- lightcatcher 7y agoI believe there's work to be done for each new CPU architecture (Broadwell, Skylake (AVX-512), Cascade Lake, let alone ARM or other architectures). The code needs to be updated for things like L1 cache size, number of registers per core, and number of adders per core. So there will likely continue to be frequent work on BLAS implementations until there's some very smart optimizing and profiling compiler (which is related to what ATLAS does I think).