www.digitalmars.com         C & C++   DMDScript  

D.gnu - OpenMP support

reply Trass3r <un known.com> writes:
I wonder how much work it would be to support OpenMP in gdc seeing how most of
the magic actually happens in that libgomp library. Could that lib be used at
all (problems with GC etc?)
Nov 29 2010
parent reply Scorn <scorn scorn.net> writes:
I too wonder how much work it would be to support OpenMP in gdc. From
http://www.drdobbs.com/high-performance-computing/226300277 it seems to be that
there is also quite a lot of magic on the compiler side (but which could already
be in the gcc parts). Maybe a concurrent garbage collector would also be needed
(Leandro Lucarella worked on this for his diploma thesis).

I hope someone can help to clear this up. If not OpenMP then at least a better
support for multicore programming in one way or another will be really important
for the future of D.
Jan 05 2011
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. From
 http://www.drdobbs.com/high-performance-computing/226300277 it seems to be that
 there is also quite a lot of magic on the compiler side (but which could


already

 be in the gcc parts). Maybe a concurrent garbage collector would also be needed
 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at least a better
 support for multicore programming in one way or another will be really


important

 for the future of D.


Would take just a little bit of work, yes. ;)

Most of the heavy duty work for GCC OMP support is done by their own C
parser/internal codegen functions. So to start, will need to rewrite half of
what
is there for the DMDFE AST.
Jan 05 2011
parent reply scorn <scorn d.net> writes:
Am 05.01.2011 21:24, schrieb Iain Buclaw:

 == Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. From
 http://www.drdobbs.com/high-performance-computing/226300277 it seems to be that
 there is also quite a lot of magic on the compiler side (but which could


 already

 be in the gcc parts). Maybe a concurrent garbage collector would also be needed
 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at least a better
 support for multicore programming in one way or another will be really


 important

 for the future of D.


 Would take just a little bit of work, yes. ;)

 Most of the heavy duty work for GCC OMP support is done by their own C
 parser/internal codegen functions. So to start, will need to rewrite half of
what
 is there for the DMDFE AST.


That really sounds tempting. Maybe we should bring this up on the main D 
mailing list (whatever this is (d.learn ?)) for discussion. While this 
might at first be a gdc only solution, having a general, developer 
approved official D syntax for all three compilers (dmd, gdc, ldc) would 
be great.

Too sad that i know nothing about the gdc / gcc internals at all or 
compiler programming in general. Otherwise i would really be tempted to 
start right now with implementing this ...
Jan 06 2011
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from scorn (scorn d.net)'s article

 Am 05.01.2011 21:24, schrieb Iain Buclaw:

 == Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. From
 http://www.drdobbs.com/high-performance-computing/226300277 it seems to be






that

 there is also quite a lot of magic on the compiler side (but which could


 already

 be in the gcc parts). Maybe a concurrent garbage collector would also be






needed

 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at least a






better

 support for multicore programming in one way or another will be really


 important

 for the future of D.


 Would take just a little bit of work, yes. ;)

 Most of the heavy duty work for GCC OMP support is done by their own C
 parser/internal codegen functions. So to start, will need to rewrite half of




what

 is there for the DMDFE AST.


 That really sounds tempting. Maybe we should bring this up on the main D
 mailing list (whatever this is (d.learn ?)) for discussion. While this
 might at first be a gdc only solution, having a general, developer
 approved official D syntax for all three compilers (dmd, gdc, ldc) would
 be great.


Official syntax? Question... why? We already have pragma to perform compiler-
independent tasks. ie:

LDC:
pragma(intrinsic, "llvm.frameaddress")
    void* llvm_frameaddress(uint level);

GDC:
pragma(attribute, optimize("-freg-struct-return"))
    foo getFoo();

DMD:
pragma(startaddress, foo);


A typical hello world application would likely look like this:

 void main ()
 {
   int th_id, nthreads;
   pragma(omp, parallel private(th_id))
   {
     th_id = omp_get_thread_num();
     writefln("Hello World from thread %d\n", th_id);
     pragma(omp, barrier)
     if ( th_id == 0 ) {
       nthreads = omp_get_num_threads();
       writefln("There are %d threads\n",nthreads);
     }
   }
 }


Regards
Jan 06 2011
next sibling parent reply scorn <scorn d.net> writes:
Am 06.01.2011 20:20, schrieb Iain Buclaw:

 == Quote from scorn (scorn d.net)'s article

 Am 05.01.2011 21:24, schrieb Iain Buclaw:

 == Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. From
 http://www.drdobbs.com/high-performance-computing/226300277 it seems to be






 that

 there is also quite a lot of magic on the compiler side (but which could


 already

 be in the gcc parts). Maybe a concurrent garbage collector would also be






 needed

 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at least a






 better

 support for multicore programming in one way or another will be really


 important

 for the future of D.


 Would take just a little bit of work, yes. ;)

 Most of the heavy duty work for GCC OMP support is done by their own C
 parser/internal codegen functions. So to start, will need to rewrite half of




 what

 is there for the DMDFE AST.


 That really sounds tempting. Maybe we should bring this up on the main D
 mailing list (whatever this is (d.learn ?)) for discussion. While this
 might at first be a gdc only solution, having a general, developer
 approved official D syntax for all three compilers (dmd, gdc, ldc) would
 be great.


 Official syntax? Question... why? We already have pragma to perform compiler-
 independent tasks. ie:

 LDC:
 pragma(intrinsic, "llvm.frameaddress")
      void* llvm_frameaddress(uint level);

 GDC:
 pragma(attribute, optimize("-freg-struct-return"))
      foo getFoo();

 DMD:
 pragma(startaddress, foo);


 A typical hello world application would likely look like this:

   void main ()
   {
     int th_id, nthreads;
     pragma(omp, parallel private(th_id))
     {
       th_id = omp_get_thread_num();
       writefln("Hello World from thread %d\n", th_id);
       pragma(omp, barrier)
       if ( th_id == 0 ) {
         nthreads = omp_get_num_threads();
         writefln("There are %d threads\n",nthreads);
       }
     }
   }


 Regards


Oh! I didn't know this! Then, what are we waiting for ? :-)


With official syntax i meant something like for example the Parallel.For 
extension of the Microsoft Parallel FX Framework (see: 
http://pietschsoft.com/post/2007/09/Parallel-FX-Library-Optimize-your-code-for-Mult
-Core-machines.aspx 
for example).


While it made sense for C++ to implement the openmp extensions in a 
"#pragma omp parallel for" comment style so that they are automatically 
supported by openmp c++ compilers and skipped by compilers which don't 
support these extensions, it feels just hacky when comparing it to a 
clean built in language solution like the Parallel FX extensions for the 
.Net languages. Since there do not exist as many D compilers as C++ 
compilers yet, i think it would be easily possible to have a clean 
language solution.


But anyway. If some folks would just start implementing openmp for gdc 
with a pragma compiler solution i just would be incredibly happy and 
wouldn't care at all :-)

Any volunteers ? ;-)
Jan 07 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
scorn wrote:

 Am 06.01.2011 20:20, schrieb Iain Buclaw:

 =3D=3D Quote from scorn (scorn d.net)'s article

 Am 05.01.2011 21:24, schrieb Iain Buclaw:

 =3D=3D Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. Fr=










om

 http://www.drdobbs.com/high-performance-computing/226300277 it
 seems to be






 that

 there is also quite a lot of magic on the compiler side (but which
 could


 already

 be in the gcc parts). Maybe a concurrent garbage collector would
 also be






 needed

 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at
 least a






 better

 support for multicore programming in one way or another will be rea=










lly

 important

 for the future of D.


 Would take just a little bit of work, yes. ;)

 Most of the heavy duty work for GCC OMP support is done by their own=








 C

 parser/internal codegen functions. So to start, will need to rewrite=









 half of




 what

 is there for the DMDFE AST.


 That really sounds tempting. Maybe we should bring this up on the mai=






n D

 mailing list (whatever this is (d.learn ?)) for discussion. While thi=






s

 might at first be a gdc only solution, having a general, developer
 approved official D syntax for all three compilers (dmd, gdc, ldc) wo=






uld

 be great.


 Official syntax? Question... why? We already have pragma to perform
 compiler-
 independent tasks. ie:

 LDC:
 pragma(intrinsic, "llvm.frameaddress")
      void* llvm_frameaddress(uint level);

 GDC:
 pragma(attribute, optimize("-freg-struct-return"))
      foo getFoo();

 DMD:
 pragma(startaddress, foo);


 A typical hello world application would likely look like this:

   void main ()
   {
     int th_id, nthreads;
     pragma(omp, parallel private(th_id))
     {
       th_id =3D omp_get_thread_num();
       writefln("Hello World from thread %d\n", th_id);
       pragma(omp, barrier)
       if ( th_id =3D=3D 0 ) {
         nthreads =3D omp_get_num_threads();
         writefln("There are %d threads\n",nthreads);
       }
     }
   }


 Regards


=20
 Oh! I didn't know this! Then, what are we waiting for ? :-)
=20
=20
 With official syntax i meant something like for example the Parallel.Fo=


r

 extension of the Microsoft Parallel FX Framework (see:
 http://pietschsoft.com/post/2007/09/Parallel-FX-Library-Optimize-your-c=


ode-for-Multi-Core-machines.aspx

 for example).
=20


	You mean like this:
foreach(i; pool.parallel( iota(squares.length), 100)) {
    // Iterate over squares using work units of size 100.
    squares[i] =3D i * i;
}

	It is currently under review for D2:
http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html and
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_par=
allelism.d

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 07 2011
parent reply scorn <scorn d.net> writes:
Am 08.01.2011 08:47, schrieb "Jérôme M. Berger":

 scorn wrote:

 Am 06.01.2011 20:20, schrieb Iain Buclaw:

 == Quote from scorn (scorn d.net)'s article

 Am 05.01.2011 21:24, schrieb Iain Buclaw:

 == Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. From
 http://www.drdobbs.com/high-performance-computing/226300277 it
 seems to be






 that

 there is also quite a lot of magic on the compiler side (but which
 could


 already

 be in the gcc parts). Maybe a concurrent garbage collector would
 also be






 needed

 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at
 least a






 better

 support for multicore programming in one way or another will be really


 important

 for the future of D.


 Would take just a little bit of work, yes. ;)

 Most of the heavy duty work for GCC OMP support is done by their own C
 parser/internal codegen functions. So to start, will need to rewrite
 half of




 what

 is there for the DMDFE AST.


 That really sounds tempting. Maybe we should bring this up on the main D
 mailing list (whatever this is (d.learn ?)) for discussion. While this
 might at first be a gdc only solution, having a general, developer
 approved official D syntax for all three compilers (dmd, gdc, ldc) would
 be great.


 Official syntax? Question... why? We already have pragma to perform
 compiler-
 independent tasks. ie:

 LDC:
 pragma(intrinsic, "llvm.frameaddress")
       void* llvm_frameaddress(uint level);

 GDC:
 pragma(attribute, optimize("-freg-struct-return"))
       foo getFoo();

 DMD:
 pragma(startaddress, foo);


 A typical hello world application would likely look like this:

    void main ()
    {
      int th_id, nthreads;
      pragma(omp, parallel private(th_id))
      {
        th_id = omp_get_thread_num();
        writefln("Hello World from thread %d\n", th_id);
        pragma(omp, barrier)
        if ( th_id == 0 ) {
          nthreads = omp_get_num_threads();
          writefln("There are %d threads\n",nthreads);
        }
      }
    }


 Regards


 Oh! I didn't know this! Then, what are we waiting for ? :-)


 With official syntax i meant something like for example the Parallel.For
 extension of the Microsoft Parallel FX Framework (see:
 http://pietschsoft.com/post/2007/09/Parallel-FX-Library-Optimize-your-code-for-Multi-Core-machines.aspx
 for example).


 	You mean like this:
 foreach(i; pool.parallel( iota(squares.length), 100)) {
      // Iterate over squares using work units of size 100.
      squares[i] = i * i;
 }



Yes, exactly like that! (Thanks for the hint.)



 	It is currently under review for D2:
 http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html and
 http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d

 		Jerome



Is it already usable ?


If yes, then it would really be a reason for me to switch to D2 now.
Jan 08 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
scorn wrote:

 Am 08.01.2011 08:47, schrieb "J=C3=A9r=C3=B4me M. Berger":

     You mean like this:
 foreach(i; pool.parallel( iota(squares.length), 100)) {
      // Iterate over squares using work units of size 100.
      squares[i] =3D i * i;
 }


=20
 Yes, exactly like that! (Thanks for the hint.)
=20

     It is currently under review for D2:
 http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html and
 http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_=




parallelism.d


=20
 Is it already usable ?
=20
 If yes, then it would really be a reason for me to switch to D2 now.


	I believe so although I have not tried it myself.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Jan 09 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-01-06 20:20, Iain Buclaw wrote:

 == Quote from scorn (scorn d.net)'s article

 Am 05.01.2011 21:24, schrieb Iain Buclaw:

 == Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. From
 http://www.drdobbs.com/high-performance-computing/226300277 it seems to be






 that

 there is also quite a lot of magic on the compiler side (but which could


 already

 be in the gcc parts). Maybe a concurrent garbage collector would also be






 needed

 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at least a






 better

 support for multicore programming in one way or another will be really


 important

 for the future of D.


 Would take just a little bit of work, yes. ;)

 Most of the heavy duty work for GCC OMP support is done by their own C
 parser/internal codegen functions. So to start, will need to rewrite half of




 what

 is there for the DMDFE AST.


 That really sounds tempting. Maybe we should bring this up on the main D
 mailing list (whatever this is (d.learn ?)) for discussion. While this
 might at first be a gdc only solution, having a general, developer
 approved official D syntax for all three compilers (dmd, gdc, ldc) would
 be great.


 Official syntax? Question... why? We already have pragma to perform compiler-
 independent tasks. ie:

 LDC:
 pragma(intrinsic, "llvm.frameaddress")
      void* llvm_frameaddress(uint level);

 GDC:
 pragma(attribute, optimize("-freg-struct-return"))
      foo getFoo();

 DMD:
 pragma(startaddress, foo);


 A typical hello world application would likely look like this:

   void main ()
   {
     int th_id, nthreads;
     pragma(omp, parallel private(th_id))
     {
       th_id = omp_get_thread_num();
       writefln("Hello World from thread %d\n", th_id);
       pragma(omp, barrier)
       if ( th_id == 0 ) {
         nthreads = omp_get_num_threads();
         writefln("There are %d threads\n",nthreads);
       }
     }
   }


 Regards


Wouldn't that need to be wrapped in a version statement, unrecognized 
pragmas will result in an error.

-- 
/Jacob Carlborg



 Jan 08 2011



  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


== Quote from Jacob Carlborg (doob me.com)'s article

 On 2011-01-06 20:20, Iain Buclaw wrote:

 == Quote from scorn (scorn d.net)'s article

 Am 05.01.2011 21:24, schrieb Iain Buclaw:

 == Quote from Scorn (scorn scorn.net)'s article

 I too wonder how much work it would be to support OpenMP in gdc. From
 http://www.drdobbs.com/high-performance-computing/226300277 it seems to be






 that

 there is also quite a lot of magic on the compiler side (but which could


 already

 be in the gcc parts). Maybe a concurrent garbage collector would also be






 needed

 (Leandro Lucarella worked on this for his diploma thesis).
 I hope someone can help to clear this up. If not OpenMP then at least a






 better

 support for multicore programming in one way or another will be really


 important

 for the future of D.


 Would take just a little bit of work, yes. ;)

 Most of the heavy duty work for GCC OMP support is done by their own C
 parser/internal codegen functions. So to start, will need to rewrite half








of

 what

 is there for the DMDFE AST.


 That really sounds tempting. Maybe we should bring this up on the main D
 mailing list (whatever this is (d.learn ?)) for discussion. While this
 might at first be a gdc only solution, having a general, developer
 approved official D syntax for all three compilers (dmd, gdc, ldc) would
 be great.


 Official syntax? Question... why? We already have pragma to perform compiler-
 independent tasks. ie:

 LDC:
 pragma(intrinsic, "llvm.frameaddress")
      void* llvm_frameaddress(uint level);

 GDC:
 pragma(attribute, optimize("-freg-struct-return"))
      foo getFoo();

 DMD:
 pragma(startaddress, foo);


 A typical hello world application would likely look like this:

   void main ()
   {
     int th_id, nthreads;
     pragma(omp, parallel private(th_id))
     {
       th_id = omp_get_thread_num();
       writefln("Hello World from thread %d\n", th_id);
       pragma(omp, barrier)
       if ( th_id == 0 ) {
         nthreads = omp_get_num_threads();
         writefln("There are %d threads\n",nthreads);
       }
     }
   }


 Regards


 Wouldn't that need to be wrapped in a version statement, unrecognized
 pragmas will result in an error.


To be extremely pedantic... yes.



 Jan 08 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-01-08 16:34, Iain Buclaw wrote:

 == Quote from Jacob Carlborg (doob me.com)'s article

 Wouldn't that need to be wrapped in a version statement, unrecognized
 pragmas will result in an error.


 To be extremely pedantic... yes.


A compiler is usually extremely pedantic :)

-- 
/Jacob Carlborg



 Jan 08 2011