[REVIEW] Renumber vertices

[ChuckHastings]

Created function to renumber source and dest vertices for a graph. Addresses #27

Takes an array of src vertices and dst vertices (assumed to be integer types) and generates a densely packed version of the vertex arrays and a map translating the new vertex ids back to the original vertex ids.

[GPUtester]

Can one of the admins verify this patch?

[kkraus14]

add to whitelist

[afender]

1. Would it be a lot of work to have template <typename T_in, typename T_out> in renumber.cuh:107? Since all our algorithms currently only support 32bits input that would allow loading/converting 64bit input.
2. It seems to me that 32 threadPerBlock and threadBlock lead to underoccupancy issues. Can you double check these numbers? Unless I’m missing something, 32 threadPerBlock covers only 1 warp, which means warps are not overlapped within an SM and 32 threadBlock covers only the first 32 SM.

[ChuckHastings]

• Would it be a lot of work to have template <typename T_in, typename T_out> in renumber.cuh:107? Since all our algorithms currently only support 32bits input that would allow loading/converting 64bit input.

Not a lot of work. I actually pondered that but didn't want to make it too complex to start. But that's an easy use case to justify. I think it's just a simple editing job to work through which things would be T_in and which would be T_out.

• It seems to me that 32 threadPerBlock and threadBlock lead to underoccupancy issues. Can you double check these numbers? Unless I’m missing something, 32 threadPerBlock covers only 1 warp, which means warps are not overlapped within an SM and 32 threadBlock covers only the first 32 SM.

I should have added a comment about those being for testing purposes. I was thinking that those parameters should not be constants. I wasn't sure if we wanted to expose them as parameters or have some heuristic computation based on the number of edges in the graph.

[afender]

Not a lot of work. I actually pondered that but didn't want to make it too complex to start. But that's an easy use case to justify. I think it's just a simple editing job to work through which things would be T_in and which would be T_out.

Let's do it then. I think this is useful.

I should have added a comment about those being for testing purposes. I was thinking that those parameters should not be constants. I wasn't sure if we wanted to expose them as parameters or have some heuristic computation based on the number of edges in the graph.

Perhaps something like this?
int nthreads = min(e,CUDA_MAX_KERNEL_THREADS);
int nblocks = min((e + nthreads - 1)/nthreads,CUDA_MAX_BLOCKS);
(see graph_utils.cuh)

[afender]

In the renumbered output, should we test that min(src U dest) = 0 and max(src U dest) = V-1 ?