[erlang-questions] Erlang and GPU libraries

[Alceste Scalas]

Il giorno mer, 05/12/2007 alle 11.24 -0700, Brian Granger ha scritto:
> We are working on GPU libraries for a number of other languages and
> Erlang might be another interesting target.  But, does Erlang have
> array/vector/matrix classes that
> 
> 1) are represented by continguous memory blocks
> 
> 2) have elements that correspond the standard C datatypes int, float, etc.
> 
> This would be needed to interface with a GPU.

I don't think you need a native Erlang data type in order to store
matrices/vectors.  Here at CRS4 we just use Erlang binaries to store
floating point arrays, and perform operations on them with our BLAS
library bindings.

In order to perform foreign function calls and handle underlying C
types, we rely on the Erlang FFI patches [1] (shameless plug).  In
theory you could do the same by developing a standard Erlang linked-in
driver, but it would require *huge* efforts.

Right now we link against ATLAS [2], but if/when we will decide to buy
some hardware based on ATI FireStream [3] or nVIDIA Tesla [4], we could
link our BLAS bindings against (respectively) ACML [5] or CUDA BLAS [6]
--- and the number crunching *should* run on GPUs transparently [7].

Regards,

alceste

References:

[1] Foreign Function Interface for Erlang/OTP
    http://muvara.org/crs4/erlang/ffi

[2] Automatically Tuned Linear Algebra Software
    http://math-atlas.sourceforge.net/ 

[3] ATI FireStream 9170
    http://ati.amd.com/products/streamprocessor/specs.html

[4] nVIDIA Tesla
    http://www.nvidia.com/object/tesla_computing_solutions.html

[5] AMD Core Math Library
    http://developer.amd.com/acml.jsp

[6] nVIDIA Compute Unified Device Architecture
    http://developer.nvidia.com/object/cuda.html

[7] It would work out-of-the-box and maintain the functional style 
    of our BLAS bindings, since matrices/vectors would be garbage
    collected by the Erlang VM.  However, it would also cause a
    dramatic overhead, since all data would be copied to/from GPU
    memory before/after each operation.  It would be possible to
    substitute floating point binaries with GPU memory references,
    but allocations and deallocations would require manual
    handling, and the functional API style would be lost (unless
    we find some trick to circumvent the issue --- but we didn't
    investigate it yet).

-- 
Alceste Scalas <alceste@REDACTED>
CRS4 - http://www.crs4.it/