Both Futhark and APL have a rich algebra of program transformations (ie they are “factorizable”), and they have a better vocabulary of data-parallel array operations than Factor. Futhark in particular is designed to run on the GPU, and Aaron Hsu designed a dialect of APL (co-dfns) for GPU execution. So they are better choices than Factor.
It’s not actually true that Joy, Factor and other concatenative languages are “maximally factorizable” in any absolute sense. Instead, these languages are designed to prioritize one particular axis of factorizability (that which involves point free code, written as a series of function compositions), at the expense of being worse along the other axes. There’s a lot more to the algebra of program transformations than just the monoid of function composition.
Aaron Hsu designed a dialect of APL (co-dfns) for GPU execution
(iirc the co-dfns compiler is not bootstrapped only for minor and uninteresting reasons. there is nothing fundamental about apl that makes it not amenable to efficient execution on massively data-parallel processors. though something for associativity would be nice since it is important and difficult to infer automatically in general)
As I understand it, co-dfns compiles APL into C++ code using the Arrayfire GPU library, which is AOT compiled. The resulting program executes initially on the CPU, allocates arrays on the CPU, executes GPU kernels to perform operations on these arrays. It’s a mixed execution model; some aspects of the APL code are executed on the CPU and other on the GPU.
APL is a highly dynamic language, this makes it more challenging to execute on the GPU than Futhark, which is statically typed and includes array ranks in the static type system.
I understand that Co-dfns has slowly increased the percentage of the APL language that it supports over the lifetime of the project. Co-dfns does not support the execute function ⟨⍎⟩, which executes a string interpreted as APL code: that would require a JIT compiler for Arrayfire code.
I wonder whether this would be easier using a language designed to be maximally factoriseable (spelling?), like Factor.
The present work is written in Futhark, which is a functional array language that is specifically designed to be run on GPUs.
Aaron Hsu’s pioneering GPU based optimizing compiler is written in APL, which has excellent algebraic properties, and which also has a very rich vocabulary of data-parallel operations.
Both Futhark and APL have a rich algebra of program transformations (ie they are “factorizable”), and they have a better vocabulary of data-parallel array operations than Factor. Futhark in particular is designed to run on the GPU, and Aaron Hsu designed a dialect of APL (co-dfns) for GPU execution. So they are better choices than Factor.
It’s not actually true that Joy, Factor and other concatenative languages are “maximally factorizable” in any absolute sense. Instead, these languages are designed to prioritize one particular axis of factorizability (that which involves point free code, written as a series of function compositions), at the expense of being worse along the other axes. There’s a lot more to the algebra of program transformations than just the monoid of function composition.
(iirc the co-dfns compiler is not bootstrapped only for minor and uninteresting reasons. there is nothing fundamental about apl that makes it not amenable to efficient execution on massively data-parallel processors. though something for associativity would be nice since it is important and difficult to infer automatically in general)
As I understand it, co-dfns compiles APL into C++ code using the Arrayfire GPU library, which is AOT compiled. The resulting program executes initially on the CPU, allocates arrays on the CPU, executes GPU kernels to perform operations on these arrays. It’s a mixed execution model; some aspects of the APL code are executed on the CPU and other on the GPU.
APL is a highly dynamic language, this makes it more challenging to execute on the GPU than Futhark, which is statically typed and includes array ranks in the static type system.
I understand that Co-dfns has slowly increased the percentage of the APL language that it supports over the lifetime of the project. Co-dfns does not support the execute function ⟨⍎⟩, which executes a string interpreted as APL code: that would require a JIT compiler for Arrayfire code.