4 ms·

We've proven that we can also speed up IO-bound and disk-bound workloads. Memory-bound jobs are not an issue either. In fact, 12GB Nvidia and AMD GPUs were ann

by tonydiv 13y ago

We've proven that we can also speed up IO-bound and disk-bound workloads. Memory-bound jobs are not an issue either. In fact, 12GB Nvidia and AMD GPUs were announced this week.

fiatmoney 13y ago
I don't doubt that you have, although I would be curious about the mechanism. Spindles are spindles, whether they're feeding to a GPU or a CPU. I would be careful about phrasing it as "memory bound is not an issue". There's a distinction between memory bandwidth (which GPUs excel at as long as the data is resident), memory latency (which GPUs are pretty bad at), and memory capacity. 12gb is slim in the grand scheme of things; my laptop has 16gb and you can get machines with >1TB of memory. Outside of the GPU's memory limits, you're relying on streaming data to/from the device, and potentially bound on PCIe bandwidth, or partitioning the problem across multiple GPUs/machines.
- Hydraulix989 13y ago
  Right. These problems are all addressable. We're using a streaming scheme to ensure that the bus bandwidth is fully utilized for each GPU. Moreover, a dispatcher will intelligently partition and distribute jobs across multiple hosts.
- tonydiv 13y ago
  Correct. PCIe is the least of our concerns at 16GB/s. Some of our tests indicate that our GPU analyzes data at a rate of ~5GB/s. If we can feed it the data in that amount of time, we're in business. We're also parallelizing disk reads, which is one bottleneck at this point.
hendzen 13y ago
A lot of academic work has been done on using GPUs for general purpose workloads. I would recommend familiarizing yourself with the literature if you have not already. Some work that may be interesting to you is the idea of Persistent Thread Groups [0]. Also, have you considered using Xeon Phi instead of GPUs? Seems like this would be a perfect use case, and it would probably be much easier to work with x86. [0] - http://cs.olemiss.edu/heroes/persistentThread.pdf http://cs.olemiss.edu/heroes/persistentThread.pdf
wmobit 13y ago
But the 64-bit pointer support isn't there yet, so it's not super useful. You can't use it all within the same program

by tonydiv 13y ago

We've proven that we can also speed up IO-bound and disk-bound workloads. Memory-bound jobs are not an issue either. In fact, 12GB Nvidia and AMD GPUs were announced this week.

fiatmoney 13y ago

I don't doubt that you have, although I would be curious about the mechanism. Spindles are spindles, whether they're feeding to a GPU or a CPU. I would be careful about phrasing it as "memory bound is not an issue". There's a distinction between memory bandwidth (which GPUs excel at as long as the data is resident), memory latency (which GPUs are pretty bad at), and memory capacity. 12gb is slim in the grand scheme of things; my laptop has 16gb and you can get machines with >1TB of memory. Outside of the GPU's memory limits, you're relying on streaming data to/from the device, and potentially bound on PCIe bandwidth, or partitioning the problem across multiple GPUs/machines.

Hydraulix989 13y ago
Right. These problems are all addressable. We're using a streaming scheme to ensure that the bus bandwidth is fully utilized for each GPU. Moreover, a dispatcher will intelligently partition and distribute jobs across multiple hosts.
tonydiv 13y ago
Correct. PCIe is the least of our concerns at 16GB/s. Some of our tests indicate that our GPU analyzes data at a rate of ~5GB/s. If we can feed it the data in that amount of time, we're in business. We're also parallelizing disk reads, which is one bottleneck at this point.

hendzen 13y ago

A lot of academic work has been done on using GPUs for general purpose workloads. I would recommend familiarizing yourself with the literature if you have not already. Some work that may be interesting to you is the idea of Persistent Thread Groups [0]. Also, have you considered using Xeon Phi instead of GPUs? Seems like this would be a perfect use case, and it would probably be much easier to work with x86. [0] - http://cs.olemiss.edu/heroes/persistentThread.pdf http://cs.olemiss.edu/heroes/persistentThread.pdf

wmobit 13y ago

But the 64-bit pointer support isn't there yet, so it's not super useful. You can't use it all within the same program