cmu-sei / gbtl Goto Github PK

cuspbackend::matrix constructor is slightly different from that of sequential::matrix (and frontend::matrix, for that matter) in terms of how zeroes are treated. need to fix this.

however, if the only time a structural zero is used is at negation, and negate needs to take a semiring to get its ones and zeroes, there is really no point in storing a separate zero at the matrix level, eh?

There are numerous performance issues that need to be addressed when time allows.

need to support masked mxm either natively or adding a stage of post-processing.

solved in PR #35

as discussed at IPDPS

MJ Anderson's paper:
GraphPad: Optimized Graph Primitives for Parallel and Distributed Platforms

We need a proper sparse implementation of the sequential backend first, so that we can remove the manual definition of structural zeros in the Matrix class

...unless it shall be decided later that we actually want structural zeros to be matrix-specific.

in assign test, we have:
vect_I({1,2})
...
when the matrix in question has only 2 rows (0,1)
which was assumed to have taken from the math doc

while in extract, indices start at 0.

will change tests in assign to favor indices starting at 0

see title

Need to either restrict swap to matrices that have the same number of rows and columns or handle different sizes.

Need to decide if apply+binaryop should stay gone (in c++ lambdas and std::bind are idiomatic options).

If it should be restored then we need some sort of enable-if mechanism.

After the GraphBLAS API call of 2 October we have new more explicit C++ naming standards:
The namespace: GraphBLAS API operations: will be 'camelCase' except for matrix multiplies as follows: buildMatrix, mXm, extractTuples
In addition an mxm_demo.cpp must be written (adapt mxm_test.cpp) and use the specific values from the homework assignment.
This will need to committed to the API bitbucket repo.

At the current stage, we cannot support the negate operation without materializing the negated matrix in the cusp backend.

Need to discuss how to implement a negation mask on the GPU (searches through a COO matrix?), which probably will involve making our own matrix implementation at some point.

Add IndexT to Matrix/Vector template parameters. Accomodate elsewhere as needed.

we can apply binary masks (true/false) based on the features of the date itself, but what other possibilities a mask can have?

I am running into problems running tests for the GPU implementation of GBTL. I am thinking the issue is with the cusplibrary version I'm using not matching up with the cusplibrary you used. Could you let me know which version you used?

My system environment is:

CUDA: 10.0
nvcc: 10.0
GBTL: 1.0.0 branch
cusplibrary: develop branch (commit dc77579)

I built using make and ran the tests using run_tests.sh on two GPUs (Tesla V and K40c). The output for both looks like:

*** No errors detected
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
./run_tests.sh: line 1: 30328 Aborted                 (core dumped) ./$test

*** No errors detected
terminate called after throwing an instance of 'thrust::system::system_error'
  what():  device free failed: an illegal memory access was encountered
terminate called recursively

*** 2 failures detected in test suite "mst_suite"

*** No errors detected

*** 16 failures detected in test suite "bfs_suite"

*** No errors detected

*** No errors detected

*** 12 failures detected in test suite "sssp_suite"

*** No errors detected

*** No errors detected

*** No errors detected

*** 2 failures detected in test suite "maxflow_suite"

*** No errors detected

*** No errors detected

*** No errors detected

Full error log: https://gist.github.com/ctcyang/09cffca92d64bd3c9bc63300c9122f5f

Instead of iterating over the elements of the LilMatrix's as if they were dense we need to intersect and union index sets to determine which elements to access.