4 ms·
The big problem with using array languages for lower-level SIMD stuff is that that generally requires some amount of typedness, but tacking on types on an array
by dzaima 2y ago
The big problem with using array languages for lower-level SIMD stuff is that that generally requires some amount of typedness, but tacking on types on an array language without ending up with having types be the majority of the syntax and code (or taking up a ton of mental capacity if utilizing very heavy type inference) would be rather non-trivial. And the operations you want for lower-level ops are quite different from the higher-level general-purpose ones too. (and, of course, some interpreters do make good use of SIMD and/or multithreading)
That said, some form of array language more suited for stuff like that is a somewhat common question; maybe one day someone will figure it out.
Vanessa McHale is doing some interesting work on a typed compilable array language, Apple[0].
[0]: https://github.com/vmchale/apple/?tab=readme-ov-file#apple-array-system https://github.com/vmchale/apple/?tab=readme-ov-file#apple-a...
- pjmlp 2y agoThanks for the hint. While we have CUDA being polyglot, it is still pretty much C and C++, or shader languages, hence why I keep thinking why not an array language that is also a kind of shader language DSL.
- dzaima 2y agoOh, another interesting thing is http://beyondloom.com/tools/specialk.html http://beyondloom.com/tools/specialk.html - a simple k DSL for shaders. Though it still follows the shader language paradigm of running the function for each pixel separately, rather than the array language paradigm of taking & returning a list of things to process.