The problem with co-processor-based programming (graphics, sound, network protocol) is that it takes a lot of time to get data in and out of the co-processor. It only works well when you have a lot of processing to do on the same dataset. And a dataset that fits (along with intermediate products) in the co-processor card's memory.
Gaming has this use case: you download relatively small amounts of 3D data and the card repetitively walks it and regenerates the screen. It (I assume) does not upload much processed data. Even cooler is the Python thing that reads Python byte-codes and gets compiled code onto the card. Lance On Tue, Sep 28, 2010 at 2:38 AM, deneche abdelhakim <[email protected]> wrote: > Cool! thanks for the link =D > > --- En date de : Mar 28.9.10, Ashwin Jayaprakash > <[email protected]> a écrit : > >> De: Ashwin Jayaprakash <[email protected]> >> Objet: AMD's new Aparapi (A PARallel API) - GPU for Java programs >> À: [email protected] >> Date: Mardi 28 septembre 2010, 3h14 >> >> This might be of interest to some folks here: AMD's new >> Aparapi (A PARallel >> API) , an API that allows programmers to write logic in >> Java to be executed >> on a GPU. >> >> Article: http://www.infoq.com/news/2010/09/aparapi-java-and-gpus >> http://www.infoq.com/news/2010/09/aparapi-java-and-gpus >> >> -- >> View this message in context: >> http://lucene.472066.n3.nabble.com/AMD-s-new-Aparapi-A-PARallel-API-GPU-for-Java-programs-tp1593604p1593604.html >> Sent from the Mahout User List mailing list archive at >> Nabble.com. >> > > > > -- Lance Norskog [email protected]
