|
|
|
|
|
|
by jcranmer
35 days ago
|
|
|
Have you read the entire paper, and not just skimmed the front matter? The interface is a generic template approach, which can work on any element type T, not just float/double/complex<float>/complex<double>, but custom types like bigint or rational or random_custom_finite_field. Or integration with units libraries (there's another dumpster fire coming down the line...). Your BLAS library will provide you just the four basic element types, so it takes a decent amount of dispatch logic to convert the template interface to the actual library calls, and you still need fallback logic anyways to handle the other types. But the library is also not designed in a way to facilitate that kind of dispatch logic (std::simd is, which accounts for a not insubstantial portion of its complexity). Which is on top of the difficulty of linking to one of various BLAS implementations as a standard library. So it's a design that's all but guaranteed to let you link against an existing BLAS implementation, and indeed, carefully reading the rest of the section you wrote makes it clear that it's not a goal of the paper proposal to have implementations do that. |
|
|
so, your problem with it is that it does all you want (e.g. LAPACK bindings) AND give extra features??
> so it takes a decent amount of dispatch logic to convert the template interface to the actual library calls
I can't estimate how much this degrades performance. But, it feels very low overhead compared to the calculation itself (and probably should be resolved at compile time)