3 ms·

Your explanations really help! I think I can see where k/APL-alike proponents are coming from; the semantics make sense, and it'd come down to recognizing what

Your explanations really help! I think I can see where k/APL-alike proponents are coming from; the semantics make sense, and it'd come down to recognizing what symbols or group of symbols do. It might take a bit of going back and forth with a reference, but it isn't impossible. Yet another question: how would performance analysis of this function work? Does the interpreter actually materialize arrays for stuff like (x='(')-x=')', so you'd have several iterations over the entire input array? Again, thanks for your great explanations! I'll definitely put k on my list of languages to explore in my free time.

beagle3 7y ago
Yes, almost all current interpreters and compilers do materialize the results and making whole passes through the array in such a case. In practice, since the primitives (e.g. “=“) are implemented in tight, predictable, branch free, often SIMD code, it ends up faster than the obvious branching C-like routine despite the interpreter overhead - especially since any strung under 16K is essentially guaranteed to be in L1 for the 2nd pass (and even if it’s not - it’s predictable linear prefetched access even in the first pass, almost as good). When was the last time you wrote prefetching branchless SIMD code for any task other than your inner loop? In APL/K you pay interpreter and GC overhead, but often get those perks for your whole program “for free”. Indeed, k/APl make use of your visual pattern matching in ways that no other language does (or can, with standard practices, due to code density). Some APl compilers identify idioms and replace them with a faster implementation (e.g. sum which is +/ is done by essentially all, more complicated things like “average” by some); but the cognitive load is independent of that - you don’t need a manual because a semantically equivalent implementation is in front of your eyes.
- aw1621107 7y ago
  The closest thing I can think of to prefetching branchless SIMD code was some numpy scripts I did some work with, but I'm not sure it would be quite as tightly optimized. It's really quite fascinating, and I'll have to see if I can handle the pattern matching as well as the more experienced APLers here. Thanks for taking the time to answer my questions!
  - beagle3 7y ago
    You’re welcome.

beagle3 7y ago

Yes, almost all current interpreters and compilers do materialize the results and making whole passes through the array in such a case. In practice, since the primitives (e.g. “=“) are implemented in tight, predictable, branch free, often SIMD code, it ends up faster than the obvious branching C-like routine despite the interpreter overhead - especially since any strung under 16K is essentially guaranteed to be in L1 for the 2nd pass (and even if it’s not - it’s predictable linear prefetched access even in the first pass, almost as good). When was the last time you wrote prefetching branchless SIMD code for any task other than your inner loop? In APL/K you pay interpreter and GC overhead, but often get those perks for your whole program “for free”. Indeed, k/APl make use of your visual pattern matching in ways that no other language does (or can, with standard practices, due to code density). Some APl compilers identify idioms and replace them with a faster implementation (e.g. sum which is +/ is done by essentially all, more complicated things like “average” by some); but the cognitive load is independent of that - you don’t need a manual because a semantically equivalent implementation is in front of your eyes.

aw1621107 7y ago
The closest thing I can think of to prefetching branchless SIMD code was some numpy scripts I did some work with, but I'm not sure it would be quite as tightly optimized. It's really quite fascinating, and I'll have to see if I can handle the pattern matching as well as the more experienced APLers here. Thanks for taking the time to answer my questions!
- beagle3 7y ago
  You’re welcome.