Live data from Hacker News

Functional Programming for Array-Based Parallelism

infoq.com

1–10 of 23 posts

Re: Functional Programming for Array-Based Parallelism

#2
Great slides near the end, this project looks really fun, and it's cool to see parallelism applied to simple vanilla code--rather than having to build the transformation through some eDSL. That said, I hate to be a downer, but I've really moved away from Haskell, so I don't see myself playing with this. Lately it's PyTorch or PySpark, with an eye on Rust, and mildly Julia.

Re: Functional Programming for Array-Based Parallelism

#3
One of the most elegant paper series I've ever read is her "More Types for Nested Data Parallelism" (https://dl.acm.org/doi/abs/10.1145/351240.351249) + the preceding NESL / segmented scan papers by Guy Blelloch (https://www.cs.cmu.edu/~guyb/papers/Nesl2.0.pdf) . They helped lead to our GPU journey for starting Graphistry, and why we bet on GPU dataframes (ex: RAPIDS.ai) eventually overtaking Spark and friends even before DataBricks was a company :) If you do pandas/tensorflow/numpy/sql/etc., this stuff is amazing.

Fun to see come full circle here!

Re: Functional Programming for Array-Based Parallelism

#4
post #2

Great slides near the end, this project looks really fun, and it's cool to see parallelism applied to simple vanilla code--rather than having to build the transformation through some eDSL. That said, I hate to be a downer, but I've really moved away from Haskell, so I don't see myself playing with this. Lately it's PyTorch or PySpark, with an eye on Rust, and mildly Julia.

why's that?

Re: Functional Programming for Array-Based Parallelism

#8
post #2

Great slides near the end, this project looks really fun, and it's cool to see parallelism applied to simple vanilla code--rather than having to build the transformation through some eDSL. That said, I hate to be a downer, but I've really moved away from Haskell, so I don't see myself playing with this. Lately it's PyTorch or PySpark, with an eye on Rust, and mildly Julia.

> but I've really moved away from Haskell

Eh? Some sort of ML (or maybe Lisp) is going to be at the cutting edge in something like this where you have JIT-compilers and such.

> Lately it's PyTorch or PySpark

There's some GPU stuff you can do in Python via Futhark. It's very cool.

Re: Functional Programming for Array-Based Parallelism

#9
post #3

One of the most elegant paper series I've ever read is her "More Types for Nested Data Parallelism" ( https://dl.acm.org/doi/abs/10.1145/351240.351249 ) + the preceding NESL / segmented scan papers by Guy Blelloch ( https://www.cs.cmu.edu/~guyb/papers/Nesl2.0.pdf ) . They helped lead to our GPU journey for starting Graphistry, and why we bet on GPU dataframes (ex: RAPIDS.ai) eventually overtaking Spark and friends ev…

Seconded! I had the pleasure of taking Guy Belloch's parallel programming class at CMU as a sophomore. A large majority of the homework assignments involved leveraging the segmented scan operator to solve all sorts of classical parallel programming problems.

Really eye opening stuff! I am still impressed that prefix sum (generalized over all associative operators, not just +) can be done in O(log n) span. And the algorithm is not too complicated either, I was able to get the gist of it even as an undergrad.

Re: Functional Programming for Array-Based Parallelism

#10
I saw her keynote of this talk at Lambda Days, and it was easily my favorite talk there this year (except mine, of course :) ).

I find it kind of weird that, outside of academic circles and the like, Haskell is largely dismissed as "not practical"; I think the "cabal hell" days before Stack came out really hurt the language and its adoption. Libraries like Accelerate really demonstrate how powerful something like Haskell can be when applied correctly.

Post reply on HN