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