Thanks for explaining this. I will go according to this. - Janardhan
On Fri, May 11, 2018 at 10:14 AM, Matthias Boehm <mboe...@gmail.com> wrote: > This particular JIRA is only partially related. Niketan and Nakul > worked out the details - the only reason I show up as the reporter is > that, if I remember correctly, we split a larger scoped JIRA for > low-level optimizations (GPU, codegen, compression) into individual > JIRAs and created the detailed tasks. > > Overall, I believe that sparse GPU operations would be very valuable, > especially in the context of NLP, graphs, and structured data with > categorical features (which often become very sparse after dummy > coding) because in these ultra-sparse scenarios dense operations cause > unnecessary overheads of orders of magnitude (proportional to the > sparsity). However, creating efficient sparse GPU kernels is > challenging due to irregularities (e.g., sparsity skew). Compared to > CPU operations, there might still be benefit depending on the data > location of inputs/outputs, as well as higher memory bandwidth. > > Even in the face of extending the codegen framework for GPUs (which is > still on the roadmap for this year), we would still need dense/sparse > kernels for the individual operations because we want to apply codegen > only if we can benefit from fusion. Right now we call existing > libraries such as cuBLAS and cuDNN and have dense kernels for a subset > of operations such as unary and binary, and unary aggregates. > > Regarding ramping up on the GPU backend, maybe it's a good idea to > first start with missing dense operations. I'm thinking of statistical > functions (e.g., covariance, moment), parameterized builtin functions > (e.g., grouped aggregated), missing unary and binary operations (e.g., > bitwise), missing reorg operations (e.g., reshape, sort - there should > be library for the latter), missing unary, binary and ternary > aggregates, missing nary (e.g., nary cbind/rbind), etc. Adding these > remaining operations would also help a lot. However, if you're more > interested in contributing to the development of sparse kernels, maybe > you could one or two dense operations, get comfortable, and then move > on to sparse operations. Apart from the kernels, a seamless support > for sparse operations would also require some integration work on how > we pass data, maintain nnz, preallocate sparse outputs, etc. > > Regards, > Matthias > > > On Thu, May 10, 2018 at 8:47 PM, Janardhan <janard...@apache.org> wrote: > > Hi Matthias, > > > > Was this related to long term plan for GPU codegen? > > > > Thank you, > > Janardhan >
