4 ms·
GPUs and analytic DBMSes / query engines are actually my own field of research (https://eyalroz.github.io); https://eyalroz.github.io); and it's obviously beyon
by einpoklum 6y ago
GPUs and analytic DBMSes / query engines are actually my own field of research (https://eyalroz.github.io); https://eyalroz.github.io); and it's obviously beyond what a comment would encompass, but:
1. There are very few analytic DBMSes which are actually fast (and compare against reasonable baselines). Most claims of speed are bogus. Or rather, might be better than what's otherwise available to use, but are still slow.
2. Designing an analytic DBMS to properly utilize a massively-parallel processing device is a monumental task, and I would claim that it has not yet been undertaken. Existing research and production systems graft such use onto a system whose fundamental design dates back to the 1980s in many ways.
3. CPU-utilizing anallytic DBMSes are typically faster than GPU-based ones, to a great extent due to the above - but also since we've had decades of work on optimizing them.
4. GPUs are artificially handicapped on Intel-architecture systems, because they are placed "far" from main memory relative to the CPU. More literally - the bandwidth you get t between your GPU and main memory is typically 0.25x the bandwidth a CPU socket has with main memory. This is critical for analytic query processing (as opposed to neural network simulation which is more computation-heavy and can tolerate this handicap much better).
--
PS - Always glad to discuss this further with whoever is interested.
- jacques_chester 6y agoHow do you see your general observations applying to AresDB?
- einpoklum 6y agoI have not undetaken a serious analysis of AresDB; and on their part, Uber has not - to my knowledge - published any in-depth design description or benchmark results. I definitely see some key useful concepts mentioned in that blog post, but there are others which I don't really see presented (or that are associated with what's described as future work). I realize it's FOSS, but - I can't just go read their sources. My intuition says that they're probably doing a decent-but-not-optimal job for their own use-case and are not planning on developing it into something more general. Specifically, the fact that they only accept their own query language is fishy. I also note that the public repository on GitHub has not been updated for about half a year. --- Caveat: Ares might be brilliantly designed and implemented, I can't really fault them for anything with any certainty. Just speculating here.
- nickpeterson 6y agoAs someone interested in esoteric databases, I’d be curious to hear which ones you’re aware of that in your opinion don’t live up to claims or do. For instance, I’ve been very impressed with Clickhouse and have messed around with Jd (from Jsoftware ). Any other good ones I should check out?
- lokl 6y agoWhat are the best case scenarios (roughly) for GPU-based speedups of typical DB workloads? I have no sense of whether we're aiming for 2x, 10x, 1.1x.
- einpoklum 6y agoIf a GPU has K_1 times the integer or floating-point operations per second of a CPU, and K_2 the memory bandwidth to its on-GPU memory than a CPU to overall system memory, then the absolute best improvement you can reasonably hope for is somewhere between K_1 and K_2. For a typical CPU and typical corresponding GPU (note the highly exact terminology here...) K_1 and K_2 are give-or-take, 10x or so. Now, it might be a lot less than 10x if your use of the GPU is suboptimal in any way, which means you don't really have a lot of leeway for non-optimality in your design. Plus, there's the handicap I mentioned in main-memory bandwidth - while the GPU's on-board memory is much smaller. On the other hand - whoever said that the system you're measuring against is making optimal use of CPU resources? It may very well not, in which case the computation and memory throughput ratios are not upper bounds at all. Just remember that if someone tells you "I got a 50x speedup by porting this to a GPU!" - then more likely than not, their baseline was a massively sub-optimal system. Which is not to say their work is without merit: Improving the performance of a real-life system does make actual work go faster, today, rather than pursuing a dream of future optimality.
- lokl 6y agoThanks!
- bronxbomber92 6y agoHow much would the trade offs change if GPUs shared the same main memory as CPU?
- einpoklum 6y agoNot sure I understand exactly which trade-off you're referring to, but on systems without the GPU-handicapping (e.g. IBM Power; and also when you put link up many GPUs together with NVLink) - there is still a significant design and implementation challenge to produce a full-fledged analytic DBMS, competitive vis-a-vis the state-of-the-art CPU-based systems. There are also other considerations such as: The desire to combine analytics and transactions; performance-per-Watt rather than per-processor; performance-per-cubic-meter; existing deployed cluster hardware; vendor lock-in risk; etc.
- nojvek 6y agoHere’s also a big misconception. When a CPU runs it has access to the entire memory (or more specifically, a process can chew up almost all available memory if allowed). The cost of copying from RAM to L1|2|3 cache is lot lower than GPU. GPU on the other hand is slightly complex. It behaves like lots of small CPUs with their own local memory. They can access the full swath of memory but in parts and copying between the two is much more expensive. If the problem can be boiled down to map on GPU and reduce, then GPU excels. If the problem is serial or can be parallelized with SIMD instructions, CPU will run circles around GPU. SIMD has come pretty far.