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
