3 ms·

I love J. It's elegant, expressive, and concise. Just like regex, it looks like line noise at first, but that is because it's designed to get its job done as ef

by jph00 9y ago

I love J. It's elegant, expressive, and concise. Just like regex, it looks like line noise at first, but that is because it's designed to get its job done as efficiently as possible. I think it would be a wonderful way to write deep learning modules, since it is such a powerful tensor manipulation language. Unfortunately however, even although it should be perfectly suited to SIMD and GPU acceleration, this work hasn't been done yet. So it ends up not really being fast enough for modern numeric programming - but I hope one day someone smarter than me will invest in making this happen. I should add that the J community is wonderfully helpful. If you decide to take the plunge in learning this great language, be sure to join the mailing list.

throwaway7645 9y ago
If you get the chance, check out Aaron Hsu's work. He wrote a compiler that converts Dyalog APL to C++ for high performance stuff...I can't remember if GPU or what. He goes over the code in several YouTube videos and HackerNews posts. First class stuff. I think Dyalog sells it as a product.
Athas 9y ago
APL (and J by extension) are more tricky to parallelise than you might expect. The frequent reliance on boxing leads to irregular pointer structures, and the absence of compile-time type information makes it hard to generate code at all. APL is usually based on efficient implementations of primitives, but that is certainly too fine-grained to be sufficient for bandwidth-starved devices such as GPUs. I contributed to an APL-to-GPU compiler[0], and it was hard to make it work on more than a small (well-behaved) subset. [0]: https://github.com/melsman/apltail https://github.com/melsman/apltail
- 1539583023 9y ago
  Dyalog seem to have done amazing work on this in the last few years. Talk about Dyalog onging performance work https://video.dyalog.com/Dyalog16/?v=2AeONlTj1aY https://video.dyalog.com/Dyalog16/?v=2AeONlTj1aY. Latest version performance info https://www.dyalog.com/dyalog/dyalog-versions/160/performance.htm https://www.dyalog.com/dyalog/dyalog-versions/160/performanc...
deleted 9y ago
[deleted]
kazinator 9y ago
> it looks like line noise at first, but that is because it's designed to get its job done as efficiently as possible. Myth: line noise syntax required for efficient machine code. Teenagers believed this about C versus Pascal in the 1980's. "Stuff like while (* s++ = * d++); looks faster so it must be." Or else, what do you mean by efficiency? Cheaper software engineering life-cycle, end-to-end? Fewer keystrokes?

by jph00 9y ago

throwaway7645 9y ago

If you get the chance, check out Aaron Hsu's work. He wrote a compiler that converts Dyalog APL to C++ for high performance stuff...I can't remember if GPU or what. He goes over the code in several YouTube videos and HackerNews posts. First class stuff. I think Dyalog sells it as a product.

Athas 9y ago

APL (and J by extension) are more tricky to parallelise than you might expect. The frequent reliance on boxing leads to irregular pointer structures, and the absence of compile-time type information makes it hard to generate code at all. APL is usually based on efficient implementations of primitives, but that is certainly too fine-grained to be sufficient for bandwidth-starved devices such as GPUs. I contributed to an APL-to-GPU compiler[0], and it was hard to make it work on more than a small (well-behaved) subset. [0]: https://github.com/melsman/apltail https://github.com/melsman/apltail

1539583023 9y ago
Dyalog seem to have done amazing work on this in the last few years. Talk about Dyalog onging performance work https://video.dyalog.com/Dyalog16/?v=2AeONlTj1aY https://video.dyalog.com/Dyalog16/?v=2AeONlTj1aY. Latest version performance info https://www.dyalog.com/dyalog/dyalog-versions/160/performance.htm https://www.dyalog.com/dyalog/dyalog-versions/160/performanc...

deleted 9y ago

[deleted]

kazinator 9y ago

> it looks like line noise at first, but that is because it's designed to get its job done as efficiently as possible. Myth: line noise syntax required for efficient machine code. Teenagers believed this about C versus Pascal in the 1980's. "Stuff like while (* s++ = * d++); looks faster so it must be." Or else, what do you mean by efficiency? Cheaper software engineering life-cycle, end-to-end? Fewer keystrokes?