This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [libstdc++-v3 parallel mode] lack of __gnu_parallel::copy and inconvenience of transform overload
- From: Johannes Singler <singler at ira dot uka dot de>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, Bernard Hugueney <bernard at bernard-hugueney dot org>
- Date: Thu, 19 Mar 2009 10:30:43 +0100
- Subject: Re: [libstdc++-v3 parallel mode] lack of __gnu_parallel::copy and inconvenience of transform overload
- References: <eed7a5d30903170901h13a1ce74s52c865f6ec56b78@mail.gmail.com> <eed7a5d30903170933v7eee3432m4141f9092cc769d7@mail.gmail.com> <49BFDA6E.2080907@oracle.com>
Paolo Carlini wrote:
> Hi,
>> While using __gnu_parallel, I could not guess nor find the reason not
>> to have a __gnu_parallel::copy, which should be embarrassingly
>> parallel for random iterators. I settled for __gnu_parallel::transform
>> using an identity Op, which brings me to my second question/remark :
>> given that the overload of std:transform (for 1 or 2 input sequences)
>> interferes with the additional optional parameter for __gnu_parallel::
>> algorithms, would it be possible to provide
>> __gnu_parallel::transform1(...,__gnu_parallel::_Parallelism ) and
>> __gnu_parallel::transform2(...,__gnu_parallel::_Parallelism ) to allow
>> an easy selection of the parallelism of the transform algorithms over
>> 1 and 2 input sequences ?
Hmm, is there no way to solve this ambiguity otherwise? Are you using
the version from trunk?
> Johannes, what do you think? Are you already aware of this kind of
> request? Should we add it to libstdc++/38875?
That's a good idea. However, I cannot promise too much speedup for an
operation that (normally) does nothing else than accessing memory.
-- Johannes