If anyone is interested in getting this setup I put together some install notes along with some speed bumps I encountered while benchmarking Alenka a few months back: http://tech.marksblogg.com/alenka-open-source-gpu-database.h...
Alenka: GPU database engine
31–40 of 54 posts
Re: Alenka: GPU database engine
#32For postgres checkout https://github.com/pg-strom/devel
I don't think the development of pg-strom is still active, as far as I can tell
Re: Alenka: GPU database engine
#33Earlier quoted context omitted.
There are several reasons 1. GPU RAM storage isn't as fine grained as CPU virtual memory. While GPU's have virtual memory they don't have the same degree of Copy On Write hardware utilities. This make rolling back snapshots and transactions within memory very difficult. 2. GPU's don't have dedicated non-volatile storage (well some do, but it is used more as a cache, and is treated as volatile). So for loading data yo…
Your first point is an implementation detail. Why couldn't CPU RAM be used as well in a GPU database system? Re CPU vs GPU performance you are neglecting the fact that GPU RAM can be an order-of-magnitude faster than CPU RAM, not to mention the fact that complex queries can often become compute bound (geospatial queries are a prominent example).
Why couldn't CPU RAM be used as well in a GPU database system?
CPU vs GPU performance you are neglecting the fact that GPU RAM can be an order-of-magnitude faster than CPU RAM,
1. GPU MMU's are less advanced, so they don't handle transactions well (see above comments).
2. As you can't perform transactions efficiently, you need read only data. Which is possible but many databases aren't read only, or databases NOT being written too are rare.
3. Ensuring your full dataset can fit in GPU memory (typically <20GB) is a damning limitation. Streaming data into the GPU is rather sloppy and limits compute though-put.
Re: Alenka: GPU database engine
#34Earlier quoted context omitted.
There are several reasons 1. GPU RAM storage isn't as fine grained as CPU virtual memory. While GPU's have virtual memory they don't have the same degree of Copy On Write hardware utilities. This make rolling back snapshots and transactions within memory very difficult. 2. GPU's don't have dedicated non-volatile storage (well some do, but it is used more as a cache, and is treated as volatile). So for loading data yo…
Your first point is an implementation detail. Why couldn't CPU RAM be used as well in a GPU database system? Re CPU vs GPU performance you are neglecting the fact that GPU RAM can be an order-of-magnitude faster than CPU RAM, not to mention the fact that complex queries can often become compute bound (geospatial queries are a prominent example).
The CPU / RAM is a bottleneck between the persistent storage and the fast GPU.
There's a well-known way to increase network throughput and reduce latency by running a whole dedicated IP stack + hardware driver in the user space of the process that needs it. This removes the bottleneck of the OS kernel.
I wonder if there's a way to remove the bottleneck in the GPU case by something similar, by dedicating a piece of hardware to the SSD interconnect without having a CPU as an intermediary. AFAICT you still cannot DMA from a disk directly to GPU RAM, even though you have enough PCIe lanes coming to the GPU. Is this true? If so, can it change in a way that is still compatible with traditional, "normal" operation of the PC architecture?
Re: Alenka: GPU database engine
#35I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…
You're thinking about transactional databases, and you're right. Transactional databases will probably not benefit hugely from a GPU. That's not saying it's impossible, but probably not worth the effort. However, there are so many types of databases around. Lambda architectures are all the rage now - you keep one database for your transactionals, and another for analytics. Analytics are huge, in the multi-billions of…
Doesn't the overhead of moving things back and forth between GPU memory and main memory wipe out most potential gains, though?
If you're running analytical workloads on big data sets, you're typically I/O bound to start with. It seems like managing moving little pieces of it back and forth to the GPU to compute is going to be a big PITA, add lots of little latencies, and gain you absolutely nothing. What am I missing there?
Re: Alenka: GPU database engine
#36Earlier quoted context omitted.
> GPU h264 encoders Are there any GPU (shader) encoders? There are dedicated fixed-function hardware encoders (VCE and NVENC) on graphics cards, and they're very popular, because they're the best way to record game footage if you don't have dedicated capture hardware. You don't want x264/5 hogging the CPU when you're playing games!
The fixed-function encoders are now less than half as good (that is, they require double the bitrate for same quality) as x264. Anyone who is serious about streaming gets a 8-core CPU or maybe a second computer to do the encoding.
No way it's double. 1.5x maybe. And they have H.265 now (in Polaris cards).
Not everybody can afford that setup, and I think even an 8-core will struggle with 4K…
Re: Alenka: GPU database engine
#37Earlier quoted context omitted.
You're thinking about transactional databases, and you're right. Transactional databases will probably not benefit hugely from a GPU. That's not saying it's impossible, but probably not worth the effort. However, there are so many types of databases around. Lambda architectures are all the rage now - you keep one database for your transactionals, and another for analytics. Analytics are huge, in the multi-billions of…
Doesn't the overhead of moving things back and forth between GPU memory and main memory wipe out most potential gains, though? If you're running analytical workloads on big data sets, you're typically I/O bound to start with. It seems like managing moving little pieces of it back and forth to the GPU to compute is going to be a big PITA, add lots of little latencies, and gain you absolutely nothing. What am I missing…
At Blazing we also build GPU db and have always loved what this project (Alenka) is doing. First of all when you are talking about I/O bound which I/O are you talking about? Do you mean from disk? From RAM? There are many ways of getting around some of these I/O bottleknecks like sending compressed data or processing while transferring. You're assumption that these workloads are typically I/O bound is correct but then agian GPU databases aren't always going after the most "typical" workloads. If you are doing large amounts of transformations, or complicated joins then you also can benifite hugely from the use of a gpu. Ever try to join several tables together across multiple columns? If you do then you should probably use a hash join and if you are using a hash join you better believe you are going to want to do be doing computationally intensive things like sorting and hash generation. Have you tried any gpu databases to see if this concern is valid? GPU dbs can take advantage of things like very expensive cascading compression that many normal databases can't.
Re: Alenka: GPU database engine
#38Earlier quoted context omitted.
You're thinking about transactional databases, and you're right. Transactional databases will probably not benefit hugely from a GPU. That's not saying it's impossible, but probably not worth the effort. However, there are so many types of databases around. Lambda architectures are all the rage now - you keep one database for your transactionals, and another for analytics. Analytics are huge, in the multi-billions of…
Doesn't the overhead of moving things back and forth between GPU memory and main memory wipe out most potential gains, though? If you're running analytical workloads on big data sets, you're typically I/O bound to start with. It seems like managing moving little pieces of it back and forth to the GPU to compute is going to be a big PITA, add lots of little latencies, and gain you absolutely nothing. What am I missing…
1. Not everything needs to be pushed up to the GPU. Some things are better left in RAM.
2. What if you only push indexes or similar up to the GPU, like an AB-tree index? You're keeping all of the 'heavy' stuff down, and only uploading a representation of it, to be later replaced with the actual data.
3. Think compression/decompression done on the GPU directly.
Re: Alenka: GPU database engine
#39I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…
I agree that at one point GPU h264 encoding was lower quality. But it's always been much faster, for me.
And today's NVENC h264 encoding quality is approaching x264 levels of quality, until you get to the lower end of the bit rate spectrum. x264 really shines at bpp values of 0.05 and lower, a feat NVENV has yet to achieve.
Re: Alenka: GPU database engine
#40I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…
You're thinking about transactional databases, and you're right. Transactional databases will probably not benefit hugely from a GPU. That's not saying it's impossible, but probably not worth the effort. However, there are so many types of databases around. Lambda architectures are all the rage now - you keep one database for your transactionals, and another for analytics. Analytics are huge, in the multi-billions of…
Different approaches and solutions for transactional processing and analytics, decision-making informed by data analysis, all that's been around for decades along with its own silly jargon - OLAP, OLTP, data mining...