INO benefit of using GPU for implementing APL (and J) primiivies is questionable. Most primitives are simple and the efficiency of APL/J comes the processing large arrays. The time needed to read/write GPU memory for large array is not justified unless the job is highly looped eg, encoding/decoding jpeg.
Пн, 20 июн 2016, JGeneral написал(а): > Interesting recent projects, > > TAIL - typed array intermediate language > http://www.elsman.com/pdf/array14_final.pdf > > uses structures very similar to J's internal noun format. (all of the items > are the same anyway, though it perhaps only has int and double data types) > > Semantics for core operations are similar to J (take with negative index > takes from the end) > > > used with a SML apl to TAIL compiler > > https://github.com/melsman/apltail/ > > A more interesting project is the Futhark language, and its leveraging of the > above 2 projects to target GPUs, and extends datatypes to char, bool, tuples. > > Futhark feels higher level and cleaner than TAIL. > > > spec paper: http://futhark-lang.org/publications/fhpc16.pdf > > more general overview/benchmark/example site: > > http://futhark-lang.org/index.html > > pretty much every link there is interesting. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
