Re: [boost] Interest in a GPU computing library

Subject: Re: [boost] Interest in a GPU computing library
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-09-19 02:23:33

On 09/18/2012 08:06 PM, Eric Niebler wrote:
> On 9/18/2012 10:45 AM, Andrey Semashev wrote:
>> On Tuesday 18 September 2012 13:58:24 Felipe Magno de Almeida wrote:
>>> Could it use boost.phoenix v3? IUC, Phoenix v3 creates a boost.proto
>>> expression. The library could make transformations to these
>>> expressions.
> Yes, phoenix was designed to make this sort of application possible.
Indeed.
>> Phoenix actors do contain Proto expressions. But as I understand, actors and
>> the additional components Phoenix implements to evaluate expressions in a
>> functional manner are useless in context of Boost.Compute.
> True, you would need a different back-end.
Indeed.
>> IIUC, the
>> constructed expressions are not invoked but translated into strings (the C99
>> source code). Using Proto directly seems more appropriate.
> Just because you need a different back-end doesn't mean the phoenix
> front-end is worthless. Phoenix has defined a schema that maps C++
> statements onto C++ expressions and provides the components to build
> these expressions for you. To ignore that and rebuild it from scratch
> seems like a waste to me.
>
> Besides, having a way to take a single phoenix expression and evaluate
> it in different ways -- on a CPU with the built-in Phoenix evaluators,
> or on a GPU with alternate ones -- sounds bloody cool, and very useful.
>
I have to fully agree here. The external transforms we put tremendous 
effort into were designed for exactly that purpose. I would not like to 
see this going to waste hand have yet another lambda library 
implemented. I even put up an example for this 
http://www.boost.org/doc/libs/1_51_0/libs/phoenix/example/parallel_for.cpp 
(Ok, this is for openmp, but i think it shows the basic direction one 
could go). Instead of executing the expression in the evaluation you 
create a string and be done with it. Reuse a subset of the already 
existing phoenix expressions, generate an error on the unsupported ones, 
use the phoenix extension mechanism to create Boost.Compute "overloads" 
for regular functions. Bloody cool indeed and on my list from day 1 we 
had the external transforms in place.
So question to Kyle is: What did you miss from phoenix 3?