Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#71

Post by _zoltan_ »

winwang wrote: post #56
threeseed wrote: post #51

Earlier quoted context omitted.

I've used GPU based Spark SQL for many years now and it sounds flashy but it's not going to make a meaningful difference for most use cases. As you say the issue is that you have an overall process to optimise from getting the data off slow GCS onto the nodes, shuffling it which often then writes it to a slow disk before the real processing even starts then writing back to a slow GCS.

Not sure what your use cases are, but I haven't had too much issue seeing good gains vs bare Spark -- GCS has not been my bottleneck.

would you be able to share a runtime with operator breakdown for the curious ones among us?

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#72

Post by winwang »

debarshri wrote: post #70

It reminds me of Hadoop days, where the data would be stored in the HDFS and you would use mapreduce to process it. However, the concept was to send computation to the location of the data. This really make sense. I might be a little out of touch. I wonder, do you incur transfer cost when you data is in buckets and you process by bringing data to the compute.

If you stand up your compute cluster in the same region as your bucket, there are no egress fees. Otherwise, yes, in general. There are some clouds that don't have egress fees though, i.e. Cloudflare R2.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#73

Post by winwang »

_zoltan_ wrote: post #71
winwang wrote: post #56

Earlier quoted context omitted.

Not sure what your use cases are, but I haven't had too much issue seeing good gains vs bare Spark -- GCS has not been my bottleneck.

would you be able to share a runtime with operator breakdown for the curious ones among us?

That's a pretty interesting idea, might take a bit to prepare a useful graphic/post.

Also, what do you think would be the best way to structure such a post?

But, here's a small bit of something perf-y: during large shuffles, I was able to increase overall job performance/efficiency by using external shuffles, even with times of ~5s median shuffle write for a couple hundred MB partitions (I hope I'm remembering this correctly, lol). This is not particularly great, but it did allow for cost-efficiently chewing through some rather large datasets without dealing with memory issues. There's also an awesome side benefit in that it allows us to use cheap spot workers in more scenarios.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#75

Post by sitkack »

> I was trying to craft a CUDA-based lambda calculus interpreter

This is awesome!

I assume you have seen https://github.com/HigherOrderCO/Bend https://github.com/higherorderco/hvm

Previous discussions https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#76

Post by zackmorris »

winwang wrote: post #30
zackmorris wrote: post #20

Earlier quoted context omitted.

Came here to say the same thing. Set Theory is the classical foundation of SQL: https://www.sqlshack.com/mathematics-sql-server-fast-introdu... It's analogous to how functional programming expressed through languages like lisp is the classical foundation of spreadsheets. I believe that skipping first principles (sort of like premature optimization) is the root of all evil. Some other examples: - If TCP had been a lay…

I'm not sure about the rest of your comment, but we would likely still want GPUs even with highly multicore CPUs. Case in point: the upper-range Threadripper series. It makes sense to have two specialized systems: a low-latency system, and a high-throughput system, as it's a real tradeoff. Most people/apps need low-latency. As for throughput and efficiency... turns out that shaving off lots of circuitry allows you to…

Ya I winced after I wrote that and am considering taking a break from posting for a while. I'm just really tired of suffering the status quo because many people love it if it aligns with their worldview, while people like me who see things a little differently seem condemned to struggle in isolation. I've always admired Tesla, not Edison, but the Edison way of doing business seems to win out and suppress the people on the fringe.

As for GPUs, they are useful for languages like GNU Octave (MATLAB) and Julia. Although there's a code smell with that. The matrix languages that would benefit most from SIMD seem to be the ones that aren't hardware accelerated on GPUs. Something has gone wrong:

https://news.ycombinator.com/item?id=8302256

That was over 10 years ago and I doubt the situation is any better today. Misaligned incentives.

I feel that the missing link is direct hardware access to the GPU ALUs. Without being able to transpile CPU code to GPU code and vice versa to provide bare metal multithreading and vector operations, we miss out on a whole branch of computer science. We can't do the interesting experiments that I always rant about, which would make stuff like genetic algorithms borderline trivial. We're stuck with cookie cutter solutions like OpenGL, Vulkan, Metal, etc.

Yet we still praise Nvidia, even though like Microsoft/Intel in the 1990s, they're probably most responsibly for stifling innovation in multicore computing.

For what it's worth, you're right about the latency/throughput tradeoff. I don't mind stuff like Intel's integrated graphics or Apple's M line of processors with integrated GPU and NPU cores for raw throughput and efficiency. I just think they're silly because they operate at the wrong layer: 1) CPU 2) multicore 3) GPU. There's no layer 2. Why is that?

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#77

Post by winwang »

zackmorris wrote: post #76
winwang wrote: post #30

Earlier quoted context omitted.

I'm not sure about the rest of your comment, but we would likely still want GPUs even with highly multicore CPUs. Case in point: the upper-range Threadripper series. It makes sense to have two specialized systems: a low-latency system, and a high-throughput system, as it's a real tradeoff. Most people/apps need low-latency. As for throughput and efficiency... turns out that shaving off lots of circuitry allows you to…

Ya I winced after I wrote that and am considering taking a break from posting for a while. I'm just really tired of suffering the status quo because many people love it if it aligns with their worldview, while people like me who see things a little differently seem condemned to struggle in isolation. I've always admired Tesla, not Edison, but the Edison way of doing business seems to win out and suppress the people o…

Gotcha, no problem.

> while people like me who see things a little differently seem condemned to struggle in isolation

Haha, you should consider founder life then. I think many founders feel like this.

The issue with transpiling to GPUs is that it is really hard to do that in a sensible, performant way. Something something a sufficiently smart compiler... There is plenty of @jit in Python, and there's TornadoVM for JVM.

Nvidia's CUDA has been around since the 2000s and is somehow still best way to program for GPUs still. Probably the best SIMT-oriented stack at all, even. From my perspective, it's everyone else stifling themselves.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#79

Post by winwang »

s2radhak wrote: post #78

congrats on the launch! curious what solution you have for the data locality problem, especially when integrating with s3/gcs/blobstore

Depends on the workload. Spark can persist dataframes to the cluster as normal. GPUs can also load certain datasets significantly faster.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#80

Post by winwang »

sitkack wrote: post #75

> I was trying to craft a CUDA-based lambda calculus interpreter This is awesome! I assume you have seen https://github.com/HigherOrderCO/Bend https://github.com/higherorderco/hvm Previous discussions https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Indeed I have, though I have some reservations about its focus on interaction nets (or rather, its marketing).

I ended up making a CUDA-based, data-parallel STLC typechecker (Hindley-Milner)... I want to formally prove its correctness first, but maybe a blog post would be okay either way.

Post reply on HN