Discussion for creating ArrayFire lua API

[pavanky]

@gpryor This need not be implemented immediately. But it would be nice to have a discussion going on about this.

[ghost]

Quite - I think more of a Torch contribution would be better

[pavanky]

Yes indeed, but I think it would be nice to have a general purpose library in LUA first and then integrate with Torch.

[ghost]

I have time to contribute to Torch - not the general lib. :/

[pavanky]

Sure, just need your input on how to get started. Once the rest of the team implements the base API you can look into integrating with Torch.

[ghost]

Whoa - I would learn Torch. Beyond that for general lib would dive into LuaJIT. C bindings from LuaJIT are almost transparent and effortless.

[ggcrunchy]

Hi.

The v3.1 announcements of a few days ago came just as I've been wanting a more powerful linear algebra solution, so I'd actually be willing to have a go at this in a couple weeks or so.

I guess I'd just grind my way through this list, plus any classes that show up in their signatures? Apart from a few operators (operator= and the mutate ones) it looks straightforward enough...

Was there already more discussion on this elsewhere? Are there any conventions that have arisen in the other language bindings that should be followed?

(This would be stock Lua, since that's what I need at the moment. Though indeed, as @gpryor says, LuaJIT bindings shouldn't present much trouble at all.)

[pavanky]

@ggcrunchy The ideal way is to wrap the C API functions rather than C++. I was thinking of beginning work on this at some point soon as well. Perhaps I can create the skeleton and we can split up the work between us ?

[ggcrunchy]

Sounds great.

For context, my plan is to piggyback on this effort to make a plugin (Windows initially, more as time goes on) for the Corona SDK, where the primary language is Lua.

[ghost]

I have no idea if this email is going to make it from my phone or not, but I'm going to give it a try nonetheless.

I highly suggest taking a dive into what is known as luapower. Packaging and bundling system across OSs is really second to none and could really help out such a project.

Moreover, I would also suggest preliminary investigation into Terra the goal being a very deep and possibly alcohol induced philosophical journey through its purpose and contributions.

I would say that the simplicity of Lua, the beautifully simple LLVM interface provided by Tara, and the immense library of data-parallel functions provided by arrayfire presents an opportunity that I feel is great, but can't quite put my finger on.

Moving purely down the Lua front, it would be a tremendously valuable exercise to consider problems regarding unstructured data that are the typical orthogonal set to which arrayfire is geared.

Hopefully that's a good few cents. Looking forward to activity on the lua front! On Sep 20, 2015 18:48, "Steven Johnson" notifications@github.com wrote:

Sounds great.

For context, my plan is to piggyback on this effort to make a plugin (Windows initially, more as time goes on) for the Corona SDK, where the primary language is Lua.

— Reply to this email directly or view it on GitHub https://github.com/arrayfire/arrayfire-lua/issues/1#issuecomment-141842508 .

[ggcrunchy]

@gpryor

I've taken cursory looks in the past at both toolkits. I'm not sure whether "such a project" referred to my plugin or this binding, but I'll keep Luapower's packaging / bundling in mind.

As far as "problems... to which arrayfire is geared", my foremost use case will be 2D graphcut textures, following Kwatra et al.. I've got the bare minimum done, but the various refinements, at least per the authors' recommendations, call for FFTs / convolution, summed area tables, and multiresolution splines. SATs in stock Lua worked well, I found, but suffice it to say any but the most tiny of 2D FFTs did NOT. :smiley: I have a second application involving thin-plate splines that uses QR decomposition as a first step. (LU ought to work too.) Up to around 40 x 40 a pure Lua implementation has been fine, then the cost ramps up rather quickly.

I also regularly see questions for CV- and audio analysis-related problems, so this being available could finally change some of the answers from "somebody has to provide the mechanisms" to "somebody has to sit down and implement it".

[ghost]

understood - seems like arrayfire is the right tree to which to bark then

luajit is attractive due to it's ffi

terra gives you the same ffi, but plugs the entirety of LLVM behind it. we have done extensive analysis of the machine code emitted by both tools and have found terra to be superior for the data-parallel cases you outline.

have lots of fun!

in the end, using whatever and using luapower/bundle will get you a tool that you can actually distribute!

Steven Johnson writes:

@gpryor

I've taken cursory looks in the past at both toolkits. I'm not sure whether "such a project" referred to my plugin or this binding, but I'll keep Luapower's packaging / bundling in mind.

As far as "problems... to which arrayfire is geared", my foremost use case will be 2D graphcut textures, following Kwatra et al.. I've got the bare minimum done, but the various refinements, at least per the authors' recommendations, call for FFTs / convolution, summed area tables, and multiresolution splines. SATs in stock Lua worked well, I found, but suffice it to say any but the most tiny of 2D FFTs did NOT. :smiley: I have a second application involving thin-plate splines that uses QR decomposition as a first step. (LU ought to work too.) Up to around 40 x 40 a pure Lua implementation has been fine, then the cost ramps up rather quickly.

I also regularly see questions for CV- and audio analysis-related problems, so this being available could finally change some of the answers from "somebody has to provide the mechanisms" to "somebody has to sit down and implement it".

---

Reply to this email directly or view it on GitHub: https://github.com/arrayfire/arrayfire-lua/issues/1#issuecomment-141896790

Sent with my mu4e

[ghost]

oh yes - - another note

for our mutual benefit, could you send over the assembly for your projects from whatever toolset you are using?

if you let us know the exact hardware you're running on, grep 'model name' /proc/cpuinfo, we can let you know if your tool is short-changing you or not.

Will be fun. Best of luck!

Oh to be in grad school again... to be in the 20's again... to avoid three-year-olds predicting death at scraped knees again! Gosh.

Gallagher Pryor writes:

understood - seems like arrayfire is the right tree to which to bark then

luajit is attractive due to it's ffi

terra gives you the same ffi, but plugs the entirety of LLVM behind it. we have done extensive analysis of the machine code emitted by both tools and have found terra to be superior for the data-parallel cases you outline.

have lots of fun!

in the end, using whatever and using luapower/bundle will get you a tool that you can actually distribute!

Steven Johnson writes:

@gpryor

I've taken cursory looks in the past at both toolkits. I'm not sure whether "such a project" referred to my plugin or this binding, but I'll keep Luapower's packaging / bundling in mind.

As far as "problems... to which arrayfire is geared", my foremost use case will be 2D graphcut textures, following Kwatra et al.. I've got the bare minimum done, but the various refinements, at least per the authors' recommendations, call for FFTs / convolution, summed area tables, and multiresolution splines. SATs in stock Lua worked well, I found, but suffice it to say any but the most tiny of 2D FFTs did NOT. :smiley: I have a second application involving thin-plate splines that uses QR decomposition as a first step. (LU ought to work too.) Up to around 40 x 40 a pure Lua implementation has been fine, then the cost ramps up rather quickly.

I also regularly see questions for CV- and audio analysis-related problems, so this being available could finally change some of the answers from "somebody has to provide the mechanisms" to "somebody has to sit down and implement it".

---

Reply to this email directly or view it on GitHub: https://github.com/arrayfire/arrayfire-lua/issues/1#issuecomment-141896790

Sent with my mu4e

[ggcrunchy]

@gpryor

It's completely untested at this point and lacking a few details still (locations of non-Windows binaries, CUDA- and OpenCL-specific stuff, etc.), but I went ahead and made a cdef, since in putting the stock Lua binding together I was basically iterating the whole ArrayFire function list anyhow: ArrayFire FFI

It's not 100% ready, but getting there.