Re: [boost] Interest in a GPU computing library

Subject: Re: [boost] Interest in a GPU computing library
From: Kyle Lutz (kyle.r.lutz_at_[hidden])
Date: 2012-09-19 08:20:55

On Wed, Sep 19, 2012 at 2:23 AM, Thomas Heller <thom.heller_at_[hidden]> wrote:
> 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?

Truthfully, I've never used (or even really taken a close look at)
Boost.Phoenix. The Proto library seemed to have the functionality I
needed and thus I used that.

I will take a look at Boost.Phoenix 3 and see if it will work for
Boost.Compute. Thanks for providing the example link.

Cheers,
Kyle