4 ms·

This has been tried many times. Unless you are doing a computation with sufficient arithmetic intensity [0] the cost of shipping the data over PCIe and back dom

• sitkack 10y ago
  You would need a GPU with an onboard SSD (exists). Or GPUs and drivers with the ability to talk directly to infiniband hardware (exists). Or the ability to not be ridiculously wasteful of existing resources (also exists). Your naysaying doesn't make you smart. Your naysaying makes you cut off from learning a different, better way of doing things.
  • cowsandmilk 10y ago
    BlazingDB is advertising as being run on AWS, Azure, Softlayer; do the GPUs on these systems have these hardware features?
  • brianwawok 10y ago
    Seems like a smarter response to me. Go ahead and use a GPU database if you want?? I have yet to see a good use case of one though.
    • felipe_aramburu 10y ago
      We have seen many. Big joins are our best use case. Joins are hard for many databases to optimize when they have not seen them before or are not "expecting" them like when you let amazon know how to partition your different tables onto the same physical machines so that redshift can return your query in a reasonble amount of time. But most SQL operations can be accelerated by the use of GPU's. Order by (holy smokes it helps), arithmetic or date transformations (20-30x for comparable cpu code), predicates, group by. All of these operations are happening over vectors of data. SIMD rock out when it comes to running these kinds of loads. The only use cases that we actually think are very poorly suited to gpus thus far (and this is a nut someone will one day probably crack) is wild card string searches. Some of our competitors handle this by caching all the data in GPU RAM but we consider that to be "cheating" since you would never be able to justify the pcie transfer to do wild card string searches.
      • brianwawok 10y ago
        This seems more like an analytics workload.. you are querying a bunch of things you can't index ahead of time. Why not put GPUs on your analytics machines? Or a cluster of them with SPARK. Or heck, distribute the spark cluster on top of your database.
        • felipe_aramburu 10y ago
          We are an Analytical database not a transactional one. We would love to integrate with more tools like spark alas we are a small team of 5 working on the engine and making the engine itself has taken most of our time to date.
  • hendzen 10y ago
    Database workloads tend to be very branch heavy, e.g. string comparisons. If you've ever programmed a GPU you know that taking a data-dependent branch serializes the execution of the GPU stream processing units. So already the 70-100x benefit GPUs give on vectorized floating point workloads is greatly reduced. Add in the memory bandwidth penalty and it's a complete waste for IO intensive database workloads. Save the GPUs for training neural nets and physics simulations. When the fundamental hardware capabilities of GPUs make them worth investing in for database workloads, I'll change my opinion. Until then, any budget for expensive DB hardware is much better spent on NVMe storage.
    • zlynx 10y ago
      You can write code to compare strings without branches. Imagine comparing one string to every string in a database column. Pad to a fixed size first (if you find an ambiguous match later you can do a full string compare then). Subtract the strings, aka compare, and store the result. At the end of all the commparisons you have a memory structure of negative, zero, or positive values. Then you can do something with the matching values. There have been some very sweet algorithms for doing B+ tree searches for Itanium and for AVX and those work just as well, if not better on GPU. With some thinking, branch operations can be converted into math and applied to masses of data without checking for branch conditions. This wastes some work but is still faster than branching.
      • hendzen 10y ago
        That sounds like an interesting technique - but it unfortunately does not apply on a majority of real-world data. In particular I mean sorting non-English text which any serious database needs to be able to do. Subtracting characters doesn't work when you're dealing language specific Unicode collation [0]. [0] - http://www.unicode.org/reports/tr10/ http://www.unicode.org/reports/tr10/
        • zlynx 10y ago
          Yeah, well, you just can't do it that way and be fast at the same time. I mean seriously fast. What you can do is decide how your comparison should be collated and preprocess your strings into a sort key form that is strictly big-endian binary (first byte has highest weight). Or little-endian I suppose, whichever works best for your hardware. Your sort key doesn't have to be the actual string.
• gfody 10y ago
  Seems like a great application of AMD's Fiji GPU w/onboard flash: http://www.anandtech.com/show/10518/amd-announces-radeon-pro-ssg-fiji-with-m2-ssds-onboard http://www.anandtech.com/show/10518/amd-announces-radeon-pro...
• mappu 10y ago
  Video encoders like x264 are not GPU accelerated, for the same reason.
• felipe_aramburu 10y ago
  Seems kind of like a blanket statement to make if you have not investigated this for yourself. So let me give you some example use cases. Decompression for processing: We can roundtrip decompress 8 byte integers RRleDeltaRle 4x on an AWS g2.2xlarge faster when we use the GPU. This includes sending the data TO the GPU and brining it back. Our decompression segments on CPU were set up so that every thread was processing a segment to be decompressed so we were using every avaiable thread at about 100%. Sorting data: Here the difference can be startling. On an aws g2.2xlarge we are able to sort orders of magnitude faster than you can on GPU. Checkout thrust to run some exmaples http://docs.nvidia.com/cuda/thrust/#axzz4K7CRY352 http://docs.nvidia.com/cuda/thrust/#axzz4K7CRY352 A few modifications there can let you run this with both and NVIDIA backend and one that runs on CPU threads. It will run orders of magnitude faster on GPU than CPU on a small gpu instance on amazon. Even a laptop gpu would still outperform the cpu sorting capacity by at least an order of magnitude.
• macromaniac 10y ago
  There was a paper a few months back in deep reinforcement learning that got record setting RL results using only a CPU [0]. Previously, these algorithms would play fewer games and run a gpu over and over on the few games they had played. By using a CPU you can generate more samples that are up to date with your learning algorithm. It sounds obvious in hindsight, but you can't exactly run 60 atari sims on a gpu. [0] - https://arxiv.org/abs/1602.01783 https://arxiv.org/abs/1602.01783
  • lightcatcher 10y ago
    > It sounds obvious in hindsight, but you can't exactly run 60 atari sims on a gpu. Why not? It's certainly easier to run parallel Atari sims on CPU, because CPU programs are typically written as single-threaded or with parameterized number of threads. Running parallel Atari on GPU is completely possible, with either running an Atari game on the each of ~30 SMs or each of the 32 * n_SMs ~= 1000 warps. However, because GPU code is typically written and delivered as kernels which utilize the full GPU, this type of embarrassing parallelism over SMs or warps typically can't be gained from using an existing library.
    • deleted 10y ago
      [deleted]
• mcphage 10y ago
  > This has been tried many times. How many fewer cores, and how much less GPU RAM, and how much slower were GPUs in general when this was tried? They're changing quite rapidly—significantly faster than any other component in a modern PC. Any attempts more than 2 or 3 years ago aren't very relevant.
  • scott_s 10y ago
    In my experiments in 2010, GPU speed was irrelevant. The GPU could had performed the calculations literally instantaneously, and the GPU still would have lost to the CPU by several orders of magnitude. Quoting myself, in some contexts, "data movement efficacy trumps raw computational power": http://www.scott-a-s.com/files/debs2010.pdf http://www.scott-a-s.com/files/debs2010.pdf