HackerTrans
TopNewTrendsCommentsPastAskShowJobs

tmostak

no profile record

Submissions

GPU-Accelerated Presto

prestodb.io
3 points·by tmostak·18 days ago·0 comments

Fast geospatial aggregation and visualization with Uber H3

heavy.ai
1 points·by tmostak·last year·0 comments

Benchmarking geospatial join performance on GPU vs. CPU

heavy.ai
1 points·by tmostak·last year·0 comments

comments

tmostak
·last month·discuss
GPU-accelerated databases have a long history. I founded HeavyAI (previously MapD/OmniSci) in 2013, but there are or have been many other startups in this space, such as Voltron Data, Kinetica, Sqream, etc. And now you have major players like IBM, Starburst, and Microsoft (which just announced Fabric SQL on GPU today) working on their own GPU-accelerated systems. GPUs have a huge advantage in terms of compute, memory, and interconnect bandwidth over CPU, as long as you can keep them fed with data.

I believe within 2-3 years databases and data warehouses on GPU will be common. The widespread use of agents to query data will be a part of this, as there will be a need to run far more queries at lower latency than needed for the ETL and BI workloads of the past.
tmostak
·6 months ago·discuss
Evidence (preferably with recent Teslas/HW4)?
tmostak
·6 months ago·discuss
Evidence of this? I own a Tesla (HW4, latest FSD) as well as have taken many Waymo rides, and have found both to react well to unpredictable situations (i.e. a car unexpectedly turning in front of you), far more quickly than I would expect most human drivers to react.

This certainly may have been true of older Teslas with HW3 and older FSD builds (I had one, and yes you couldn't trust it).
tmostak
·6 months ago·discuss
Do you have data to back this claim up, specifically with HW4 (most recent hardware) and FSD software releases?
tmostak
·9 months ago·discuss
Even without NVLink C2C, on a GPU with 16XPCIe 5.0 lanes to host, you have 128GB/sec in theory and 100+ GB/sec in practice bidirectional bandwidth (half that in each direction), so still come out ahead with pipelining.

Of course prefix sums are often used within a series of other operators, so if these are already computed on GPU, you come out further ahead still.
tmostak
·last year·discuss
We've made extensive use of perfect hashing in HeavyDB (formerly MapD/OmniSciDB), and it has definitely been a core part of achieving strong group by and join performance.

You can use perfect hashes not only the usual suspects of contiguous integer and dictionary-encoded string ranges, but also use cases like binned numeric and date ranges (epoch seconds binned per year can use a perfect hash range of one bin per year for a very wide range of timestamps), and can even handle arbitrary expressions if you propagate the ranges correctly.

Obviously you need a good "baseline" hash path to fall back to you, but it's surprising how many real-world use cases you can profitably cover with perfect hashing.