-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BB-27: Descriptors query and default #13
Comments
I see no problem with the write-only aspect of descriptors and therefore don't perceive a need for this capability. |
OK. this makes sense and I could see supporting this. There is a something Tim Davis has asked for repeatedly and that is that every GraphBLAS method should take a descriptor. That would give an implementation a standard way to pass extra information into a method. This makes sense to me though I hate changing the API so radically |
Every function needs a descriptor, even GrB_Matrix_nvals. I have to control parallelism. The BLAS is broken, badly, in this regard. You can't tell DGEMM how many threads to use, so an application that wants to use a parallel BLAS becomes very hard to write if you have multiple application threads calling the BLAS at the same time (say 8 cores, 2 user threads: one calls DGEMM with 5 threads and the other with 3, at the same time). With the descriptor, I can control this on a per-call basis ... but only if I have a descriptor and not all methods take a descriptor. The need to read a descriptor is from the following use case: say you have a utility function that does something, taking in a descriptor from its caller to do some work (say "do something with A transpose") but then I want to fiddle with this descriptor to change or its thread count. Maybe I want to read "oh, this descriptor says to use 5 threads inside GraphBLAS, but I want to fork so I will create 2 more descriptors and give 3 threads to one of my threads and 2 to another"). That's why I'd like to read/write a descriptor. However, I can live with a read-only descriptor (the user application would just carry around its own equivalent, which it can read/write, and then it can make a GrB_descriptor at the last moment, and it can be write-only). The main problem with descriptors is that not all functions have them, so my control over the parallel use of GraphBLAS is partial and lame. |
Adding the descriptor to all methods is another issue: #48. |
|
Make extended descriptor a separate issue |
- Issue BB-28 (#14), BB-27 (#13), BB-13 (#5), BB-7 (#4): We added a capability for meta-data associated with each GraphBLAS object and the library implementation (the global scope) as well. This was done through the new `GrB_get` and `GrB_set` methods with `(field, value)` pairs. We also needed a new error code for the case where an attempt is made to write to a write-once feild, `GrB_ALREADY_SET`. - Issue BB-15 (#7), BB-14 (#6): The definition of meta-data on GraphBLAS objects added the ability to interact directly with the type system behind these objects. This required the addition of type codes `(GrB_Type_Code)` and the ability to manage the type system through strings. - We augmented the deserialization method so if passed a type parameter of `GrB_NULL` it will infer type information needed for deserialization of a GraphBLAS matrix. - We added a new built-in descriptor `GrB_COMP_STRUCTURE` and an explicit reference to the default value of a descriptor field, `GrB_DEFAULT` --------- Co-authored-by: Jim Kitchen <[email protected]> Co-authored-by: Tim Davis <[email protected]> Co-authored-by: tgmattso <[email protected]> Co-authored-by: Erik Welch <[email protected]>
Need to be able to query contents of a descriptor, see SuiteSparse 'GxB_Desc_get'.
Need to be able to set a value of a descriptor that need not be the enum type, but any other type; see Suitesparse 'GxB_Desc_set'.
Need 'GxB_DEFAULT' to set a descriptor back to default. Currenlty a descriptor is a write-once-only object.
The text was updated successfully, but these errors were encountered: