[Bug libstdc++/31000] New: std::valarray should be annotated with OpenMP directives

[Bug libstdc++/31000] New: std::valarray should be annotated with OpenMP directives

[bangerth at dealii dot org]

Now that gcc understands OpenMP directives, it would be really cool if the
member functions of the std::valarray class could be annotated. Most of
the member functions have loops over all elements that are trivially parallel
and that could benefit from OpenMP autoparallelization. I am fairly sure
that would give a nice speedup on those numerical codes that rely on it.

Best
  Wolfgang


-- 
           Summary: std::valarray should be annotated with OpenMP directives
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bangerth at dealii dot org


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

[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-02-28 22:38 -------
Actually they could also slow down the code if the size is small enoguh.


-- 


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

[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives

[bkoz at gcc dot gnu dot org]

------- Comment #2 from bkoz at gcc dot gnu dot org  2007-03-19 11:35 -------

Wolfgang: I agree. We should have also parallelized this for SSE/Altivec a la
MacSTL.


-- 


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

[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives

[gdr at cs dot tamu dot edu]

------- Comment #3 from gdr at cs dot tamu dot edu  2007-03-19 12:40 -------
Subject: Re:  std::valarray should be annotated with OpenMP directives

"bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| 
| Wolfgang: I agree. We should have also parallelized this for SSE/Altivec a la
| MacSTL.

I suspect that parallelizing for SSE/Altivec might be more peneficial
in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla.

-- Gaby


-- 


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

[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives

[bangerth at dealii dot org]

------- Comment #4 from bangerth at dealii dot org  2007-03-19 14:03 -------
(In reply to comment #3)
> I suspect that parallelizing for SSE/Altivec might be more peneficial
> in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla.

I certainly agree. The beauty is that one may have both: SSE/Altivec/... if
the template argument of std::valarray is float/double/int (in which case one
would have to have explicit specializations of the member functions), and
OpenMP if it is anything else.

W.


-- 


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

[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives

[gdr at cs dot tamu dot edu]

------- Comment #5 from gdr at cs dot tamu dot edu  2007-03-19 15:23 -------
Subject: Re:  std::valarray should be annotated with OpenMP directives

"bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #3)
| > I suspect that parallelizing for SSE/Altivec might be more peneficial
| > in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla.
| 
| I certainly agree. The beauty is that one may have both: SSE/Altivec/... if
| the template argument of std::valarray is float/double/int (in which case one
| would have to have explicit specializations of the member functions), and
| OpenMP if it is anything else.

on my single node AMD64 machine, I would prefer the compiler to
generate codes that takes advantage of SSE than launch OpenMP.  On
the other hand, if I had multiple nodes, I might be contemplating
OpenMP for some of the valarray<double>s, so I'm not sure the issue is
that simply cut...

-- Gaby


-- 


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

[Bug libstdc++/31000] std::valarray should be annotated with OpenMP directives

[fang at csl dot cornell dot edu]

------- Comment #6 from fang at csl dot cornell dot edu  2007-03-19 18:51 -------
Subject: Re:  std::valarray should be annotated with
 OpenMP directives

> "bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes:
>
> | (In reply to comment #3)
> | > I suspect that parallelizing for SSE/Altivec might be more peneficial
> | > in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla.
> |
> | I certainly agree. The beauty is that one may have both: SSE/Altivec/... if
> | the template argument of std::valarray is float/double/int (in which case one
> | would have to have explicit specializations of the member functions), and
> | OpenMP if it is anything else.
>
> on my single node AMD64 machine, I would prefer the compiler to
> generate codes that takes advantage of SSE than launch OpenMP.  On
> the other hand, if I had multiple nodes, I might be contemplating
> OpenMP for some of the valarray<double>s, so I'm not sure the issue is
> that simply cut...

Thinking out loud...

Is there any interest/effort in placing vectorizable operations somewhere
outside of valarray so that other STL algorithms/containers might be able
to be able to leverage them?  For example, I'd like to be able to use
tr1/array on basic numeric types and have the benefits of valarray
operations without having to first copy to a valarray, which uses
heap-allocated memory.

I'm imagining something like vectorize_traits that would check for the
operation's vectorizability (std::plus) with the vectorizability of the
value_type (_Integral).  Then a subset of algorithms (<numeric> among
others) would have additional level of template-wrapping to dispatch the
appropriate __algorithm() based on vectorize_traits and iterator_traits.
One issue however might be assumptions about the aliasing of input/output
iterators... we're aware that many optimizations rely on non-aliasing
assumptions, whereas the standard algorithms make no such assumptions
(except valarray's ops).  A run-time overlap check on
random_access_iterators would incur a slight penalty.

But yes, having STL take advantage of low-level acceleration through
abstraction and compile-time polymorphism is a good thing, IMHO.

Fang


-- 


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