some of their chosen benchmarks http://arrayfire.com/benchmarking-parallel-vector-libraries/
Taking reduce as an example, J is faster than all of them for small vector sizes. about 10gbps on my system, but maxes out there. 330 timespacex '+/ a' [a=. ? 1e5 $ 1000 9.93823e_5 2176 330 timespacex '+/ a' [a=. ? 1e6 $ 1000 0.00178018 2176 at the top right corner of this page http://arrayfire.com/why-arrayfire/ They have more chosen benchmarks. J is unlikely to perform at the bottom end of the paralell libraries here, but as a rule, GPU calling overhead is responsible fo r some of the ramp up, but another portion of the ramp up is that they are using high end gpus with 448 cores (and 1024 threads per core). Consumer grade low end gpus still have 196+worker units. as a quick guide to lowerend hardware (pick bitcoin mining benchmark if not selected: https://compubench.com/result.jsp ), achieving 1/10th the high end performance is affordable (AMD A10 APU), and still very useful an intro to opencl by nvidia of all people (they developed and use CUDA primarily, though opencl is supported by newer devices) http://www.cc.gatech.edu/~vetter/keeneland/tutorial-2011-04-14/06-intro_to_opencl.pdf As part of the binary distribution of arrayfire is some precompiled benchmark programs (in examples folder). All of them are interesting, and have impressive performance on my low end hardware, but the one that addresses your comment is the hello world app. Which has extremely small dataset operations of roundtrips to the library. The cpu version still has some startup lag, but has less operational lag than the opencl/gpu version. Modifying that benchmark to show wallclock time for roundtrips would be useful. One of the benefits of ArrayFire is that it includes CPU compute libraries as well, and so medium sized inputs could be sent there with the same codebase. Having internal J covernames for every ArrayFire operation is very straightforward (I hope... assuming it does not do anything too weird), and probably more useful in many cases than the cpu libraries, but its still likely that there are middle ground cases where cpu libraries give speedup too. (new intel/amd processors are supporting opencl too, and so the future of opencl only bindings for even higher performance possibilities). Opencl is very array oriented. In my exploration of openssl's BN library, a rule of thumb is that any operation that takes longer than 0.0001s is likely to be faster with the library call. A sequence of operations that keeps the data in the library, until you want a result counts towards that 0.0001s limit. For large extended integers, there are many operations that are slower in J than that. I didn't publish the result yet, but for converting a large integer to binary/ascii, the operation is 20+x faster using BN including all memory allocation/deallocation than through J. (I forget the size of the integer I benchmarked though). The reason I bring this up is that CPU compute libraries might have similar static overhead, and the GPU overhead might be 0.001s or 0.01s, leaving that middle ground of worthwhile operations to offload. ----- Original Message ----- From: bill lam <[email protected]> To: 'Pascal Jasmin' via Programming <[email protected]> Cc: Sent: Monday, September 21, 2015 2:33 AM Subject: Re: [Jprogramming] Arrayfire (OpenCl/Cuda Blas Boost) If they have c interface, you can just call like that you had done in openssl. That said, I guess passing data in and out of GPU memory is an expensive operation. Пн, 21 сен 2015, jprogramming написал(а): > They have a c interface too. Its just harder to find the c versions of the > api sometimes. I linked to a c version of indexing in last message. (bottom > 3 of the 5 functions on that page. > > > ----- Original Message ----- > From: bill lam <[email protected]> > To: 'Pascal Jasmin' via Programming <[email protected]> > Cc: > Sent: Monday, September 21, 2015 2:07 AM > Subject: Re: [Jprogramming] Arrayfire (OpenCl/Cuda Blas Boost) > > Arrayfile looks like c++ library, it is difficult to be called > from J as a shared object. > > Пн, 21 сен 2015, jprogramming написал(а): > > I was worried about the parentheses being part of the 'operator()' name, > > but I found this page which has accessible versions: > > > > http://www.arrayfire.com/docs/group__index__func__index.htm > > > > It also looks like their span "keyword" could be a null parameter. > > > > > > ----- Original Message ----- > > From: Raul Miller <[email protected]> > > To: Programming forum <[email protected]> > > Cc: > > Sent: Monday, September 21, 2015 1:13 AM > > Subject: Re: [Jprogramming] Arrayfire (OpenCl/Cuda Blas Boost) > > > > Well, I guess we only really need 1 or 2 dimensions from AF, so maybe > > that's no big deal. And we get to decide what we call a row and what > > we call a column. > > > > Meanwhile, > > > > http://www.jsoftware.com/help/user/lib_dll.htm > > http://www.jsoftware.com/papers/jfe.htm > > > > require'dll' > > cdcb > > 15!:13 > > > > The dll callback lab in J602 explains the basic concepts. > > > > I presume it still works in J804, but someone needs to port the lab, I > > guess. (Speaking of which, I've got a different lab I need to finish > > up, also.) > > > > Thanks, > > > > -- > > Raul > > > > > > > > On Mon, Sep 21, 2015 at 12:47 AM, 'Pascal Jasmin' via Programming > > <[email protected]> wrote: > > > I did suggest a rankselect and rankamend function to the lead developer. > > > > > > AF has either a max 3 or 4 dimensions on its arrays. Its column (wrong) > > > major. > > > > > > http://www.arrayfire.com/docs/indexing.htm > > > > > > to get rows 0 and 1 from a 2d array, you would call with 0 1;(seq 0 _1). > > > For columns 1 and 2, call (seq 0 _1);1 2. One problem though is that the > > > name of the function to call is 'operator()' . Is such a name bindable > > > in J? > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: Raul Miller <[email protected]> > > > To: Programming forum <[email protected]> > > > Cc: > > > Sent: Sunday, September 20, 2015 11:28 PM > > > Subject: Re: [Jprogramming] Arrayfire (OpenCl/Cuda Blas Boost) > > > > > > One step at a time... > > > > > > (But if it was mostly ready, I guess talk with the ISI folk about > > > getting it the rest of the way?) > > > > > > -- > > > Raul > > > > > > On Sun, Sep 20, 2015 at 11:26 PM, Henry Rich <[email protected]> wrote: > > >> Fun. And very important to the future of J. > > >> > > >> But if you do something great, how do you get it into the official > > >> distribution? > > >> > > >> Henry Rich > > >> > > >> On 9/20/2015 11:22 PM, Raul Miller wrote: > > >>> > > >>> I don't think anyone has been working on this. > > >>> > > >>> Note also that J's arrays are built on a C infrastructure where a pair > > >>> of one dimensional arrays (shape and data) represent an arbitrary > > >>> dimensioned J array. > > >>> > > >>> That said... how hard do you think it would be to implement the rank > > >>> conjunction? (Rank might be better thought of as using two dimensions > > >>> for the underlying data - frame and cells.) > > >>> > > >>> Anyways, it sounds like a fun project... > > >>> > > >>> Thanks, > > >>> > > >> > > >> ---------------------------------------------------------------------- > > >> For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > 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 > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
