3 ms·

If you thought std::simd was a library nobody asked for, just wait until you hear about <linalg>. I feel like half the people looking forward to that think they

If you thought std::simd was a library nobody asked for, just wait until you hear about <linalg>. I feel like half the people looking forward to that think they're just going to get standard C++ bindings to LAPACK, when instead they're probably going to get an unoptimized, slapdash implementation of LAPACK written by people who aren't good at BLAS. As for SIMD itself, designing a good SIMD library is difficult because there are several different SIMD approaches and some of them work poorly for certain use cases. For example, you can take an HPC-ish approach of "vectorize this loop" (à la #pragma omp simd) and have the compiler take care of a fairly mechanical transformation. Or you can take an opposite approach of treating a 128-bit SIMD vector as a fundamental data type in your language. Which approach is better depends on your use case.

pwdisswordfishq 5mo ago
Just wait until you hear about std::hive. The work of one obsessive author, who never gave a good explanation for why the thing needed to be in the standard library instead of an external one. The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint. So eventually they relented. Outside coverage I have seen so far seems to be to the tune of "WTF is this weird thing?" and quickly glosses over it. I wonder if it's going to end up like the export keyword.
- tialaramex 5mo ago
  I feel like std::hive fits right in to the C++ stdlib group of collections The least stupid is std::vector which is just the typical O(1) amortized growable array type found in most modern languages, with a mediocre API. 8/10 could do better. std::array is just the built-in array type C++ should have but doesn't. This shouldn't be a library type, that's embarrassing. std::deque looks like you're getting something like Rust's VecDeque but you aren't, it's a weird hybrid optimisation which presumably made sense on some 1980s hardware. I asked STL once to explain what it's even for and they didn't know. [[For reference STL is the name of the guy in charge of Microsoft's implementation of the C++ standard library, Microsoft also calls that library STL for reasons we needn't address]] std::list is the extrusive doubly linked list. This type makes sense in a DSA class. Why is it in the C++ standard library? I dunno, maybe C++ is intended only as a teaching language? std::forward_list is the extrusive singly linked list. You know, for a different seminar in that same DSA class. You might want the intrusive linked list, you don't want this. std::map and std::set are probably red-black trees. OK, you might need those and for some reason not care about the details (which aren't specified here) std::multimap and std::multiset are even less obviously useful. I have never seem them used in real software. Why are they in the standard library? std::unordered_all_of_the_above_maps_and_sets look like the simplistic hash table you'd be shown in an intro DSA class either taught by somebody who doesn't know the subject well or aiming to cover the basics and get back to their research. This will perform poorly on any hardware with features like a cache. The C++ stdlib carries broken garbage basically indefinitely. C++ doesn't have the same library stability promise that Rust has, but in practice stuff that nobody cares about is never removed.
  - secondcoming 5mo ago
    I'm not sure what the argument is here? These are in the standard library because someone proposed their inclusion. They're fine for the majority of people who really don't want to roll their own data structures each time. They're not compulsory to use, you're still free to roll your own.
    - tialaramex 5mo ago
      > I'm not sure what the argument is here? That std::hive will fit right in. Another container type you probably shouldn't use, draining precious maintenance resource from groups who have better things they could be doing. > These are in the standard library because someone proposed their inclusion. As with std::hive. Indeed the "unordered" containers, just like std::hive were repeatedly knocked back and eventually got in decades after they were obsolete. Persistence really does pay off in C++ > They're fine for the majority of people who really don't want to roll their own data structures each time. Sure, doubtless std::hive is fine for that same majority of people.
- drysine 5mo ago
  >The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint. That's a mean interpretation, mean both towards the committee and towards the author.
feelamee 5mo ago
are u carefully read <linalg> paper[1]? It doesn't require to reimplement it... > Our proposal is inspired by and extends the dense BLAS interface. A natural implementation might look like this: > 1. wrap an existing C or Fortran BLAS library, [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r12.html#we-do-not-require-using-the-blas-library-or-any-particular-back-end https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p16...
- jcranmer 5mo 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.
  - feelamee 5mo ago
    > Your BLAS library will provide you just the four basic element types, ..., and you still need fallback logic anyways to handle the other types. 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)

pwdisswordfishq 5mo ago

Just wait until you hear about std::hive. The work of one obsessive author, who never gave a good explanation for why the thing needed to be in the standard library instead of an external one. The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint. So eventually they relented. Outside coverage I have seen so far seems to be to the tune of "WTF is this weird thing?" and quickly glosses over it. I wonder if it's going to end up like the export keyword.

tialaramex 5mo ago
I feel like std::hive fits right in to the C++ stdlib group of collections The least stupid is std::vector which is just the typical O(1) amortized growable array type found in most modern languages, with a mediocre API. 8/10 could do better. std::array is just the built-in array type C++ should have but doesn't. This shouldn't be a library type, that's embarrassing. std::deque looks like you're getting something like Rust's VecDeque but you aren't, it's a weird hybrid optimisation which presumably made sense on some 1980s hardware. I asked STL once to explain what it's even for and they didn't know. [[For reference STL is the name of the guy in charge of Microsoft's implementation of the C++ standard library, Microsoft also calls that library STL for reasons we needn't address]] std::list is the extrusive doubly linked list. This type makes sense in a DSA class. Why is it in the C++ standard library? I dunno, maybe C++ is intended only as a teaching language? std::forward_list is the extrusive singly linked list. You know, for a different seminar in that same DSA class. You might want the intrusive linked list, you don't want this. std::map and std::set are probably red-black trees. OK, you might need those and for some reason not care about the details (which aren't specified here) std::multimap and std::multiset are even less obviously useful. I have never seem them used in real software. Why are they in the standard library? std::unordered_all_of_the_above_maps_and_sets look like the simplistic hash table you'd be shown in an intro DSA class either taught by somebody who doesn't know the subject well or aiming to cover the basics and get back to their research. This will perform poorly on any hardware with features like a cache. The C++ stdlib carries broken garbage basically indefinitely. C++ doesn't have the same library stability promise that Rust has, but in practice stuff that nobody cares about is never removed.
- secondcoming 5mo ago
  I'm not sure what the argument is here? These are in the standard library because someone proposed their inclusion. They're fine for the majority of people who really don't want to roll their own data structures each time. They're not compulsory to use, you're still free to roll your own.
  - tialaramex 5mo ago
    > I'm not sure what the argument is here? That std::hive will fit right in. Another container type you probably shouldn't use, draining precious maintenance resource from groups who have better things they could be doing. > These are in the standard library because someone proposed their inclusion. As with std::hive. Indeed the "unordered" containers, just like std::hive were repeatedly knocked back and eventually got in decades after they were obsolete. Persistence really does pay off in C++ > They're fine for the majority of people who really don't want to roll their own data structures each time. Sure, doubtless std::hive is fine for that same majority of people.
drysine 5mo ago
>The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint. That's a mean interpretation, mean both towards the committee and towards the author.

feelamee 5mo ago

are u carefully read <linalg> paper[1]? It doesn't require to reimplement it... > Our proposal is inspired by and extends the dense BLAS interface. A natural implementation might look like this: > 1. wrap an existing C or Fortran BLAS library, [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r12.html#we-do-not-require-using-the-blas-library-or-any-particular-back-end https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p16...

jcranmer 5mo 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.
- feelamee 5mo ago
  > Your BLAS library will provide you just the four basic element types, ..., and you still need fallback logic anyways to handle the other types. 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)