Comparing Parallel Functional Array Languages: Programming and Performance • Hacker News Board

Re: Comparing Parallel Functional Array Languages: Programming and Performance

#21

Post by zfnmxt » Tue, May 20, 2025, 1:43 AM UTC

devlovstad wrote: post #14

I took a course on massively parallel programming taught by one of the authors of this paper that extensively used Futhark and CUDA. While I have not used any of these languages since, I have used JAX[1] quite a lot, where the learnings from this course have been quite helpful. Many people will end up writing code for GPUs through different levels of abstraction, but those who are able to reason about the semantics t…

> I took a course on massively parallel programming taught by one of the authors of this paper that extensively used Futhark and CUDA.

PMPH? :)

Re: Comparing Parallel Functional Array Languages: Programming and Performance

#22

Post by axman6 » Tue, May 20, 2025, 4:31 AM UTC

grg0 wrote: post #10

munchler wrote: post #3

Are these languages pure in the functional sense? E.g. Do they allow/encourage mutation? My understanding is that APL permits mutable state and side effects, but maybe they are rarely used in practice? If you're modifying the contents of an array in-place, I don't think it's reasonable to consider that functional.

Accelerate is a Haskell library/eDSL.

I wasn’t expecting to personally know two of the authors, but having Accelerate included makes sense.

Re: Comparing Parallel Functional Array Languages: Programming and Performance

#23

Post by yubblegum » Tue, May 20, 2025, 7:26 PM UTC

bradcray wrote: post #20

yubblegum wrote: post #2

Chapel got a mention in the 'Related Work' section. I looked at it a few years ago and found it compelling (but I don't do HPC so it was just window watching). What's the HN feedback on Chapel? https://chapel-lang.org/

@yubblegum: I'm unfairly biased towards Chapel (positively), so won't try to characterize HN's opinion on it. But I did want to note that while Chapel's original and main reason for being is HPC, now that everyone lives in a parallel-computing world, users also benefits from using Chapel in desktop environments where they want to do multicore and/or GPU programming. One such example is covered in this interview with…

Thank you Brad! I was in fact wondering about GPU use myself. Does it work with Apple's M# GPUs?

Btw, I was looking at the docs for GPU [1] and unsolicited feedback from a potential user is that the setup process needs to become less painful. For example, yesterday installed it via brew but then hit the setup page for GPU and noted I now needed to build from source.

(Back in the day, one reason some of Sun's Java efforts to extend Java's fieddom faltered was because of the friction of setup for (iirc) things like Applets, etc. I think Chapel deserves a far wider audiance.)

[1]: https://chapel-lang.org/docs/technotes/gpu.html#setup (for others - you obviously know the link /g)

p.s. just saw your comment from last year - dropping it here for others: https://news.ycombinator.com/item?id=39032481

Re: Comparing Parallel Functional Array Languages: Programming and Performance

#24

Post by bradcray » Tue, May 20, 2025, 8:15 PM UTC

yubblegum wrote: post #23

bradcray wrote: post #20

Earlier quoted context omitted.

@yubblegum: I'm unfairly biased towards Chapel (positively), so won't try to characterize HN's opinion on it. But I did want to note that while Chapel's original and main reason for being is HPC, now that everyone lives in a parallel-computing world, users also benefits from using Chapel in desktop environments where they want to do multicore and/or GPU programming. One such example is covered in this interview with…

Thank you Brad! I was in fact wondering about GPU use myself. Does it work with Apple's M# GPUs? Btw, I was looking at the docs for GPU [1] and unsolicited feedback from a potential user is that the setup process needs to become less painful. For example, yesterday installed it via brew but then hit the setup page for GPU and noted I now needed to build from source. (Back in the day, one reason some of Sun's Java eff…

@yubblegum: I'm afraid we don't have an update on support for Apple GPUs since last year's comment. While it comes up from time-to-time, nobody has opened an issue for it yet (please feel encouraged to!), and it isn't something we've had the chance to prioritize, where a lot of our recent work has focused on improving tooling support and addressing user requests.

I'll take your feedback about simplifying GPU-based installs back to our team, and have noted it on this thematically related issue: https://github.com/chapel-lang/chapel/issues/25187#issuecomm...