Comparing Parallel Functional Array Languages: Programming and Performance
1–10 of 24 posts
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#2Chapel 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?
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#3Are 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.
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#4Are 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.
Futhark, SaC, and Accelerate have purely functional semantics. Futhark has something called "in-place updates" that operationally mutate the given array, but semantically they work as if a new array is created (and are statically guaranteed to work this way by the type system).
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#5Are 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.
APL arrays are values in the same sense as value types in any functional language. You don't explicitly modify arrays in-place; if they happen to have a refcount of 1 operations may happen in-place as an optimization, but not in a manner which observably alters program behavior.
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#6Chapel 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/
If you scroll down on the Chapel-lang website, there seems to be a lot of activity happening with this language. There is even going to be a ChapelCon 2025.
https://chapel-lang.org/blog/posts/chapelcon25-announcement/
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#7Notice that all the all the languages mentioned depends on the external BLAS library for example OpenBLAS for performance.
D language have excellent support functional and array features with parallel support. On top that not known to others it has high performance native BLAS kind of library with ergonomic and intuitiveness similar to python [1].
[1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen (2016):
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#8Matlab supposedly is “portable APL”.
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#9Notice that all the all the languages mentioned depends on the external BLAS library for example OpenBLAS for performance. D language have excellent support functional and array features with parallel support. On top that not known to others it has high performance native BLAS kind of library with ergonomic and intuitiveness similar to python [1]. [1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen (201…
> Notice that all the all the languages mentioned depends on the external BLAS library for example OpenBLAS for performance.
That's incorrect. Futhark doesn't even have linear algebra primitives---everything has to be done in terms of map/reduce/etc: https://github.com/diku-dk/linalg/blob/master/lib/github.com...
Re: Comparing Parallel Functional Array Languages: Programming and Performance
#10Are 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.