Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.210.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGRH7Hp+kXDZVF9Qs-r6HiopY1oRWVKVdhpSJuBog9d45_C1bQ@mail.gmail.com>
References: <50DDA635.8080908@spaceroots.org>
 <alpine.DEB.2.02.1212281553550.2532@astropc8.ulb.ac.be>
 <50DDBF6B.4040101@spaceroots.org>
 <alpine.DEB.2.02.1212281708000.2532@astropc8.ulb.ac.be>
 <50DDC860.7060703@gmail.com> <07E3B3D2-E7AE-4BAB-8872-ED88823B6200@gmail.com>
 <50DDDDAA.2030106@free.fr>
 <CAGRH7HpruFv-2h1oGk7M091KM_VC2F6OiQYZ7dNhD4Y5=yhnNA@mail.gmail.com>
 <31C327CF-643E-4DFA-BF53-DD6BF1C6B92E@gmail.com>
 <CAGRH7Hqk_p2xueZBQM6a=Xi-Pg0AZZmqdwC7twZ96nn2uqvU_A@mail.gmail.com>
 <2416051E-2130-4EA8-93DF-389D8B95762E@gmail.com>
 <CAJwFCa0S7ZbHw3xrfVS0mtL+KMg0LDcgjS1tjHAc-KmN13SjRA@mail.gmail.com>
 <EF4991BC-3773-4E9E-B0FA-3A3E856137EF@gmail.com>
 <F5D028E6-7B3D-4872-8B9E-345B6126A3E4@gmail.com>
 <CAJwFCa25ADnBkexk8AkC8pypdBxibNKLE+XUNfdGt9JDZXGR0Q@mail.gmail.com>
 <51532DC6-D84E-40CE-A242-550C481409BD@gmail.com>
 <CAGRH7Hp+kXDZVF9Qs-r6HiopY1oRWVKVdhpSJuBog9d45_C1bQ@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Sun, 30 Dec 2012 11:43:02 -0800
Message-ID: 
 <CAJwFCa2F3zDwZ3vAZTLhRU1J5WHdFd6O-+n0=6q-ZL5WWupCnw@mail.gmail.com>
Subject: Re: [math] major problem with new released version 3.1
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=90e6ba6140da9e530404d2171c34

--90e6ba6140da9e530404d2171c34
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The GPU requires native code that is executed on the GPU.  Standard linear
algebra libraries exist for this so if the API can express a standard
linear algebra routine concisely, then the GPU can be used.  General Java
code usually can't be executed on a GPU.

There is some late breaking news on this front, but the way to get
performance is generally to recognize standard idioms that have accelerated
implementations.

In Mahout, for instance, we can recognize many linear algebra operations
from idiomatic use of visitor patterns.  For instance, in this code,

      Vector u, v;
      v.assign(Functions.PLUS, u);

Mahout will recognize the call to assign as a vector addition. This is easy
with vector operations but much harder to recognize matrix operations
expressed with simple visitor patterns.


On Sun, Dec 30, 2012 at 11:26 AM, S=C3=A9bastien Brisard <
sebastien.brisard@m4x.org> wrote:

> > and hence preclude vector based process operations, such as you would
> find
> > on a GPU. So if the user wanted to speed up the computation using a GPU
> > they would not be able to do it, if we base it on a single element at a
> > time visitor pattern.
> >
> >
> I fail to see how the GPU could not be used. I am no expert on GPU
> programming, but I can easily imagine a new implementation of RealVector,
> say GpuBasedRealVector, where the walkInDefaultOrder method would send
> multiple values at a time to the GPU. I've already done that for multi-co=
re
> machines (using fork/join), and the visitor pattern was certainly not a
> limitation.
>

--90e6ba6140da9e530404d2171c34--