Logo by mauxuam - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Visit us on facebook
 
*
Welcome, Guest. Please login or register. November 27, 2022, 12:19:39 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1] 2   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Anyone played with Arrayfire ? (CUDA/OpenCL/CPU)  (Read 7673 times)
0 Members and 1 Guest are viewing this topic.
ker2x
Fractal Molossus
**
Posts: 795


WWW
« on: February 11, 2016, 12:18:30 PM »

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

Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #1 on: February 12, 2016, 12:40:55 AM »

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.

Quote
You write "regular" C++ and the code run on GPU

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 ?
Logged
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #2 on: February 12, 2016, 07:45:48 AM »

from the array fire site...

Code:
ArrayFire is a high performance software library for parallel computing with an easy-to-use API. Its array based function set makes parallel programming simple.

it actually looks really interesting!!!

edit:worth investigating
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #3 on: February 12, 2016, 08:21:06 AM »

yeah, that doesnt actually tell us very much about it though does it
Logged
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #4 on: February 12, 2016, 02:52:38 PM »

@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 smiley
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #5 on: February 13, 2016, 01:17:42 AM »

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

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.
Logged
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #6 on: February 13, 2016, 04:02:08 AM »

@quaz0r no, not wanting to argue, the description and documentation on the website seem clear to me huh?
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?
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #7 on: February 13, 2016, 01:52:56 PM »

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.
Logged

3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #8 on: February 13, 2016, 10:13:35 PM »

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
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #9 on: February 15, 2016, 01:21:10 PM »

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

Sooo ....

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


Quote
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

@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 :
Code:
array mandelbrot(const array &in, int iter, float maxval)
{
    array C = in;
    array Z = C;
    array mag = constant(0, C.dims());
    for (int ii = 1; ii < iter; ii++) {
        // Do the calculation
        Z = Z * Z + C;
        // Get indices where abs(Z) crosses maxval
        array cond = (abs(Z) > maxval).as(f32);
        mag = af::max(mag, cond * ii);
        // If abs(Z) cross maxval, turn off those locations
        C = C * (1 - cond);
        Z = Z * (1 - cond);
        // Ensuring the JIT does not become too large
        C.eval();
        Z.eval();
    }
    // Normalize
    return mag / maxval;
}

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 smiley

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  grin

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.
Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #10 on: February 15, 2016, 01:34:21 PM »

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

Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #11 on: February 15, 2016, 03:24:54 PM »

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

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. sad
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #12 on: February 15, 2016, 03:56:54 PM »

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

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. sad

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

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

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #13 on: February 15, 2016, 04:24:07 PM »

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.

It's probably too late in the development stage to integrate arrayfire in chaotica 2  grin
Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #14 on: February 15, 2016, 06:16:31 PM »

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

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.

Logged

Pages: [1] 2   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
If you liked Assembler, you’ll love OpenCL (and Cuda too) Programming ker2x 6 3486 Last post September 06, 2010, 11:07:09 AM
by cbuchner1
New CUDA developer Meet & Greet chacharles 9 3591 Last post May 19, 2011, 01:06:00 PM
by chacharles
CUDA Benoit Announcements & News RogerDahl 7 3299 Last post April 26, 2011, 09:39:00 PM
by RogerDahl
mandelbulb3D and CUDA Programming scavenger 12 6165 Last post May 08, 2013, 01:25:50 PM
by elphinstone
CUDA Y.A.M.Z Programming « 1 2 ... 5 6 » 3dickulus 75 9178 Last post January 27, 2015, 02:38:01 AM
by 3dickulus

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.199 seconds with 24 queries. (Pretty URLs adds 0.013s, 2q)