[Bug libstdc++/38875] New: parallel fill in the parallel version of libstdc++

[wuerzner at gmail dot com]

Hi,

I recently started using the paralleled version of gcc's libstdc++. Now, I have
recognized that there is no parallel version of the fill algorithm (at least at
i486-linux-gnu).

The threshold variable __gnu_parallel::_Settings::fill_minimal_n
suggests that a parallel version of the fill algorithm is existing or at least
planned.
Among other things, fill is used for resizing vectors. But
std::vector.resize(n) is not executed in parallel. On first sight, a parallel
fill should not be hard to accomplish using openmp and would definitely be a
cool feature. But I am no stl expert and may be missing crucial
cross-dependencies.

Best regards,
Kay


-- 
   Summary: parallel fill in the parallel version of libstdc++
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wuerzner at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875

[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++

[wuerzner at gmail dot com]

--- Comment #4 from wuerzner at gmail dot com  2009-10-15 15:46 ---
Hi,

has there been any change on the std::fill policy, yet? If yes, in which
version did you integrate the parallel fill?

Many thanks,
Kay


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875

[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++

[wuerzner at gmail dot com]

--- Comment #13 from wuerzner at gmail dot com  2009-11-19 15:47 ---
If you have no speedup, do you recognize any loss of speed due to the
parallelization overhead (for small examples)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875