I agree with Skip's observation. I want to add another virtue of using J, especially for the Tegra Shield tablet ($300), and that is the pen interface. This would harvest the concise notation of J: only a few pen strokes are needed to unleash the GPU performance. A kind of combing the computational efficiency of GPU with the notational efficiency of J ;-) Jan.
On Thu, Aug 28, 2014 at 7:33 PM, Skip Cave <[email protected]> wrote: > Scott brings up an interesting point. The price for large-scale GPU > multiprocessing engines is dramatically dropping as we speak, with the > introduction of chips such as Nvidia's Tegra K1 processor, with its dual > 64-bit or quad 32-bit CPUs, and *192 GPU cores*. > > Nvidia claims that their CUDA GPU architecture "delivers 6x to 17x faster > performance than the latest MKL BLAS <https://developer.nvidia.com/cublas > >". > CUDA is Nvidias "Complete Unified Device Architecture" which includes their > Kepler GPU microarchitecure with it's unified clocking scheme. MKL BLAS is > Intel's "Math Kernel Library for Basic Linear Algebra Subroutines", > designed for Intel's various chip sets. Nvidia provides a set of > subroutines called cuBLAS for it's GPU architecture, which implements all > 152 standard BLAS routines on their CUDA GPU architecture. > > Nvidia's Tegra K1 chip is being designed into several medium and low-end > machines, such as Acer's new Chromebook 13 <http://bit.ly/1lyupUr>, which > is claimed will sell for a paltry $280. This will likely bring the > capabilities of massive GPU multiprocessing architectures to a whole new > audience. > > One of the most notable things about J is how it's set of primitives > thoroughly cover the basic data operations, and then extend those > operations to arrays in a regular manner. I can't help but wonder how much > more efficiently J's matrix operations would run, if all the primitives > took advantage of 192 GPU cores. Of course, some primitives don't lend > themselves to parallel processing, but there seems to be a large number of > primitives such as matrix divide and inverse that could be readily adapted > to utilize multiple parallel processes. > > J would appear to be positioned as a ideal high-level language for > programming parallel processes, given its primitive's thorough coverage of > basic array manipulation. > > I don't want to underestimate the difficulty of transforming J into a true > multiprocessing language. Moving J's array operations from the scalar > machine world to the multi-GPU world is far from a trivial task. However, > implementing J as a true high-level parallel processing language and > gaining 6x to 17x faster processing on array tasks, would likely do wonders > for it's visibility and usage as a programming language. > > Skip > > > Skip Cave > Cave Consulting LLC > > > On Thu, Aug 28, 2014 at 6:15 AM, Scott Locklin <[email protected]> wrote: > > > Skip wrote: > > > > >Recently, R & Python have developed fairly extensive Machine Learning > > libraries in those languages. > > >If you want to promote J, you need to show how J solves problems in a > hot > > >field like AI, better, faster, or more concisely than other languages. > > That > > >is essentially how Octave/Matlab ​got thousands of students learning the > > >language. I was tempted to try to code some of my ML homework > assignments > > >in J, but the time pressure of the weekly assignments as well as other > > >obligations, prevented that exercise. > > > > FWIIW, I am working on a few machine learning doodads for J. Though I > > have been doing Octave/matlab for 20 years, and R for 10, and J for only > a > > little while (and only on a part time basis), when I want to learn a new > > technique in detail, I code it in J. It's really living up to its > > reputation as a notation and a tool for thought. My code isn't very > dense, > > since I'm still a beginner, but it's always more clear and less wordy > than > > equivalent R or Matlab. > > > > It is a shame it isn't being used in ML research. My R&D work has > recently > > brought me in contact with the deep learning environment Torch7. There is > > no reason that couldn't have been written in J rather than Lua, and life > > would be a heck of a lot nicer if it was. It might not be too bad pulling > > CUBLAS into J via the FFI (Torch7 and Theano do this: the GPU is much > > faster on neural problems), though it would be tough figuring out how to > > turn these BLAS into J primitives. > > > > -SL > > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Jan Jacobs Esdoornstraat 33 5995AN Kessel W: www.sommaps.com T: +31 77 462 1887 M: +31 6 23 82 55 21 E: [email protected] ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
