Welcome to Fractal Forums

I just noticed that arrayfire is opensource (since at least a year) : http://arrayfire.com/

Anyone played with it ?

If you never heard about it :
You write "regular" C++ and the code run on GPU if available (try CUDA and OpenCL) or fallback to CPU.

Here is a mandelbrot exemple : http://www.arrayfire.com/docs/graphics_2fractal_8cpp-example.htm

i hate when i cant tell what something is by reading the description on the main page, nor by reading the "about" page, nor by reading some random person's explanation of it either.  thats the point where i close the tab and never think about it again.


so that means what exactly?  its like openmp/openacc ?  or its like being able to write c++ opencl code eg opencl 2.1 ?  or its one of those libraries that provides common functions except their implementation of those functions runs on the gpu instead of cpu?  why cant these sorts of explanations ever be made clear ?

from the array fire site...


it actually looks really interesting!!!

edit:worth investigating

yeah, that doesnt actually tell us very much about it though does it

@quaz0r uhm, checkout the website, look at the examples, run a few tests and then you can give an informed opinion.

@ker2x thank you for sharing this find, when I have time I will test, from reading some of the docs and looking at the code I think it is promising but need to actually dig in and try it before saying more, so little time and so many things to play with :)

sorry, you seem to want to argue with me for its own sake, and im not really sure why.  i simply stated that a proper description of this software is not made readily available by the handful of short and vague statements made on it's web site.  that is indeed my "informed opinion" of the quality of the description given for this software, an opinion informed by reading said description.   is it humanly possible to discern what any piece of software is or does by examining its source code / example programs?  sure, of course it is.  to present that as some kind of argument in response to someone stating that the description is lacking is, well, rather curious.

@quaz0r no, not wanting to argue, the description and documentation on the website seem clear to me :hmh:
when I do get to it, then I'll post some benchmark results or relate my experience with Array fire.
I am particularly interested in this http://www.arrayfire.com/docs/group__gfx__func__draw.htm and http://www.arrayfire.com/docs/machine_learning_2deep_belief_net_8cpp-example.htm and from the documentation for the functions in the library it seems pretty straight forward.

I too would like to hear of other people's experience if they have tried ArrayFire. Is it worth investing some time and energy into it?

Haven't tried it, but auto-conversion of C++ (presumably including virtual functions, new and delete, etc?) to eg OpenCL sounds like a bad idea, in practical terms.

OpenCL already runs on more or less everything, small Mandelbrot shaders are extremely trivial / not representative of software most people want to automagically port, and I'm pretty sure if you just throw a decent sized C++ program at it, it'll either fail or run dismally, simply because GPUs work very differently from CPUs and software has to be redesigned for them (with consideration for things like register pressure, branch divergence, use of shared memory etc).

Basically, I don't see how this can be useful - small Mandelbrot shaders etc are trivial in native OpenCL already, and large applications will not run better than CPU code.

there are libraries, CUDA, OpenCL, and CPU, arrayfire does not convert your code to CL or CUDA, rather, it provides access so you can exploit the hardware.

some snipets from the website,

   it supports batched operations on N-dimensional arrays,
   Each function is hand-tuned by ArrayFire developers with all possible low-level optimizations.
   can be used as a stand-alone application or integrated with existing CUDA or OpenCL code.
   You create [arrays](Constructors of array class) which reside on CUDA or OpenCL devices. Then you can use ArrayFire functions on those arrays.

my impression is that these guys have created libraries that encapsulate array management (and a bunch of other stuff) that coders would otherwise have to do "by hand" anyways and put it all into convenient libraries so that you can invest time developing ideas instead of wasting time coding the lowlevel stuff

has any one tried it yet? I am just installing the dependencies now, going to see if I can compile the libs from source on SuSE 13.2

woops, i didn't notice there was reply. Probably because i didn't expect any :D

Sooo ....

@quaz0r : yes, the website isn't coder friendly and the documentation isn't always clear.



@3dickulus : YES !


I'll try to explain :
- you don't write cuda/opencl kernel. (you can, there is a documentation about interoperability between arrayfire and your regular cuda/opencl code)
- It's not a software that "convert" regular code to something that run on GPU.
- It's all about array.

This code, from the link in my first post :

Will run on the gpu. It's still specialized code and in no way general purpose code. if you don't use af::methods it won't run on the gpu. arrayfire is just a library. But a cool one :)

The cool stuff :
- You can create (bloated) "unified" binary that will try, in order, to use the following devices : CUDA -> OpenCL -> CPU. It try to detect and use your cuda device. If the user don't have any it will try openCL device. If it still can't it will fallback to CPU only. You don't want to do this manually (you sure can but you write your code 3 times)
- Device detection & initialization is painless. You can do some custom stuff but you can also pretty much ignore it and let the lib do its stuff and hope for the best (works for me)
- lots of commonly used set of methods (computer vision, neural networks, random number generation, linear algebra, signal processing, image processing, statistics, ...).
- eg : random number generation will use CuRand if a cuda device is detected.
- provide a very simple (too limited, imho, visualisation only, no interaction) set of graphics methods : open window, 2D/3D plots, histograms, ...

I'm pretty sure it's not as efficient as handcrafted cuda/opencl kernel code.
But ... writing useable & efficient cuda/opencl code can be a major pain in the back.
Writing this "unified binary" thingy *is* a major pain in the proverbial anatomy.

imho, it worth it to try arrayfire first for new code then fallback to handcrafted kernel code if arrayfire is doing it wrong.
As someone who like to write ASM code for fun, i know that handcrafted code isn't always faster  ;D

That's pretty much it.
- Write a few line to initialize your cuda/opencl/cpu device
- write your af::array stuff
- use http://www.arrayfire.com/docs/interop_cuda.htm and/or http://www.arrayfire.com/docs/interop_opencl.htm for your handcrafted kernel code as needed (but you loose the unified binary thingy as soon as you do it)

At the very least, it's a cool (but bloated) wrapper that still let you use your handcrafted kernel.
At the very best, it's what's written on the website and it just works. Sometime a x10 speedup is enough and you don't always need more at the cost of extra development time.

That's why we have stuff like java, c#, ruby, python, php, you-name-it : they are usually slower than C/fortran/asm but your development time is reduced.

My only real concern for now is about the documentation and memory management.

Memory transfer between host and device is a major bottleneck.
As well as alignment, local vs global memory access, and all that kind of stuff.

Will i know if/how/when/why i spend all my time transferring data back and forth between host and device for silly reason ?

Of course the lack of need to manually manage the device memory is what make it much easier to use.
The same kind of problem exist with garbage collector on JVM/.NET

@ker2x have you seen this ? http://www.fractalforums.com/programming/omp-vs-par4all/msg77360/#msg77360 :)

after attempting to compile arrayfire and jumping through some hoops I'm happy with p4a^^^, arrayfire requires intel math kernel libraries @ $699 it's not feasible for me to test and I won't invest any more time into a limited trial version, it sounds great for a big corp with $$$ but the individual hacker may be left out in the cold. :(

I downloaded the free binaries : http://arrayfire.com/download/  ;D

PS : you can get intel MKL for free with the "community licencing"

It's probably too late in the development stage to integrate arrayfire in chaotica 2  ;D

Well, what I meant was, I don't see why anyone would want to use this Arrayfire stuff. Pure OpenCL is already a piece of cake really, and runs on everything - there really has to be a good reason to introduce another layer of abstraction.

We do this in our Winter programming language (which can output OpenCL code, or JIT via LLVM) to ensure safety via pure functional semantics and language restrictions. The point there is that it's totally safe to share fractal parameters with Winter code that won't root the user's computer or whatever - a concrete benefit over using raw OpenCL (or even worse, plugin DLLs) in such a context.

Can we download it ?

After Indigo 4 we've plans to open source it.

I wanted to compile from source, maybe will give it another go with the "community licencing" MKL, do you have any benchmark results to share?

Nope.
I'm sick, i'm not coding for a few days :)