Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft...
by twtw on Friday October 12, 2018 @11:00AM
(#18201853)
> copying data to the GPU (host -> device)
Copying data to the CPU (peripheral -> host) is expensive too, and it's perfectly possible to just replace peripheral -> host with peripheral -> device. I don't know if that is what blazingsql does, but it shouldn't be discounted.
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft...
by felipe_aramburu on Friday October 12, 2018 @11:03AM
(#18201881)
If you mean something like network card ==> device via RDMA we are not doing that yet but are currently working on this implementation. These past few months we have focused more on adding functionality to libgdf. We are now optimizing some of the i/os like this one you mention here. As of now if it goes over the wire it is being copied into pre allocated pinned memory buffers then sent to GPU. This will go away in about a month or so.
I'll let the BlazingSQL guys answer the workloads question, but yeah, copying data to the GPU (host -> device) is an expensive operation, and it has to be justified.
With SQream DB (disclaimer: am a developer on SQream DB), we make decisions in the query compiler and optimizer if we want to copy data over to the GPU, or keep it in CPU for processing. The optimizer will know if it makes sense.
For example, when you're doing heavy transforms (eg. `SELECT (SQRT(POWER(x,2)+44)/w+RADIANS(COS(y)*z)) FROM t`), it may make sense to have it in the GPU anyway.