4 ms·

I imagine many people are reading this with the assumption that compiled APL is obviously the next step for the language (APLers say it's fast, but it's interpr

I imagine many people are reading this with the assumption that compiled APL is obviously the next step for the language (APLers say it's fast, but it's interpreted—compiled APL must really be something!). Compiled APL is cool and all, but the performance picture is more complicated than it is for, say, Python. This is because, in high-performance interpreters, the arrays have element types that are tracked automatically, providing many of the advantages of C-like compiled languages at a fixed cost per array operation. In fact, these element types can be more accurate by dynamically adjusting to the data: with a table of unknown size the C programmer must declare indices as a 64-bit type, while APL could detect at runtime that only 16 bits are needed. APL also benefits from the higher-level notation, in that it's easier for a human to write a fast implementation of a particular operation than a compiler that can generally optimize code including that pattern (with TAIL this might not be so bad). I discussed the Replicate (like filter) operation in my talk The Interpretive Advantage[0]. Another page I wrote where you can read about array performance is [1]. APL compilers are needed in order to run code on a GPU (but if you have code that's well-suited to a GPU, it's going to be pretty fast on a SIMD CPU too). And for ML and scientific applications that work with floating-point types, the drawbacks of ahead-of-time compilation are much smaller. I think for truly general-purpose computing the best approach will be to unify interpretation and compilation, combining small groups of primitives and deciding how to run them as data becomes available. Both interpreted and compiled approaches are important in reaching this peak. [0] https://dyalog.tv/Dyalog18/?v=-6no6N3i9Tg https://dyalog.tv/Dyalog18/?v=-6no6N3i9Tg [1] https://aplwiki.com/wiki/Performance https://aplwiki.com/wiki/Performance

electroly 5y ago
This sounds like APL would benefit from a JIT runtime, which is a well-established technique in other performance-focused languages. You get all the benefits of tracking types and other data at runtime while also gaining the benefit of a compiled language.
- mlochbaum 5y ago
  Yes, the idea described in the last paragraph could be called an array JIT. Much like a static APL compiler requires specialized type and shape handling, an APL JIT would need some new techniques for deciding when to compile things, what assumptions to make, and how to check them. My more detailed notes are at https://mlochbaum.github.io/BQN/implementation/compile/dynamic.html https://mlochbaum.github.io/BQN/implementation/compile/dynam....

electroly 5y ago

This sounds like APL would benefit from a JIT runtime, which is a well-established technique in other performance-focused languages. You get all the benefits of tracking types and other data at runtime while also gaining the benefit of a compiled language.

mlochbaum 5y ago
Yes, the idea described in the last paragraph could be called an array JIT. Much like a static APL compiler requires specialized type and shape handling, an APL JIT would need some new techniques for deciding when to compile things, what assumptions to make, and how to check them. My more detailed notes are at https://mlochbaum.github.io/BQN/implementation/compile/dynamic.html https://mlochbaum.github.io/BQN/implementation/compile/dynam....