4 ms·
Not that I disagree, but to be fair, query processing on GPUs is a highly specialized task, and not quite what people think when they say "general purpose". A l
by makmanalp 10y ago
Not that I disagree, but to be fair, query processing on GPUs is a highly specialized task, and not quite what people think when they say "general purpose". A lot of work goes into writing code that utilizes that particular architecture well.
- tyingq 10y agoBecause of the memory ceiling it doesn't scale well for lots of concurrent users either... "MapD can scale to many simultaneous users. If the users are just executing hand-written SQL queries, this could be hundreds of users per server. If the users are analysts working with MapD Immerse...then you can expect tens of simultaneous users without experiencing any performance degradation." There are similar limitations around update, insert, etc. Not disputing the benefits, but it just isn't general purpose. It is for a relatively small number of users querying a huge dataset.
- otterley 10y agoThis is an issue even with non-GPU-based OLAP engines. See, e.g., Clickhouse (https://clickhouse.yandex/reference_en.html https://clickhouse.yandex/reference_en.html): "We'll say that the following is true for the OLAP (online analytical processing) scenario...Queries are relatively rare (usually hundreds of queries per server or less per second)."
- tyingq 10y agoApples and oranges measures of users vs query rate, but it sounds still like conventional OLAP can handle a lot more.
- otterley 10y agoPossibly, but I suspect that by "users," MapD really means "query rate." I can't see how a larger number of users would have a performance impact if all other variables were constant (data, query, query rate, etc.).
- arnon 10y agoIt's an in-memory database. "Huge dataset" is questionable in this scenario as it has to fit in RAM.
- amelius 10y agoHow is a query going to be faster on a GPU, when a query just performs lookups in tables, and simple comparison operations. You'd have to get the data via the CPU to the GPU in the first place, so you might as well perform the lookup/comparison on the CPU instead. Unless of course you plan to load the complete database in GPU memory, which makes the whole approach unsuited for large databases.
- lern_too_spel 10y agoThis is for analytics workloads, where you stream rows through the GPU.
- arnon 10y agoGPUs aren't good for everything. The right thing to do is balance between CPU and GPU code, and only do what actually gives any benefit. For example, GPUs suck at working on texts, or when there is a lot of divergence between processes. For example, if you have several kernels that branch to the TRUE side of the IF condition, and several that branch to FALSE, you're paying a huge performance penalty.