D.gnu - OpenMP support
- Trass3r <un known.com> Nov 29 2010
- Scorn <scorn scorn.net> Jan 05 2011
- Iain Buclaw <ibuclaw ubuntu.com> Jan 05 2011
- scorn <scorn d.net> Jan 06 2011
- Iain Buclaw <ibuclaw ubuntu.com> Jan 06 2011
- scorn <scorn d.net> Jan 07 2011
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> Jan 07 2011
- scorn <scorn d.net> Jan 08 2011
- Jacob Carlborg <doob me.com> Jan 08 2011
- Iain Buclaw <ibuclaw ubuntu.com> Jan 08 2011
- Jacob Carlborg <doob me.com> Jan 08 2011
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
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
== Quote from Scorn (scorn scorn.net)'s articleI 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
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
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
Am 05.01.2011 21:24, schrieb Iain Buclaw:== Quote from Scorn (scorn scorn.net)'s articleI 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
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
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
== Quote from scorn (scorn d.net)'s articleAm 05.01.2011 21:24, schrieb Iain Buclaw:== Quote from Scorn (scorn scorn.net)'s articleI 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
there is also quite a lot of magic on the compiler side (but which could
be in the gcc parts). Maybe a concurrent garbage collector would also be
(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
support for multicore programming in one way or another will be really
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
is there for the DMDFE AST.
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
Am 06.01.2011 20:20, schrieb Iain Buclaw:== Quote from scorn (scorn d.net)'s articleAm 05.01.2011 21:24, schrieb Iain Buclaw:== Quote from Scorn (scorn scorn.net)'s articleI 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
there is also quite a lot of magic on the compiler side (but which could
be in the gcc parts). Maybe a concurrent garbage collector would also be
(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
support for multicore programming in one way or another will be really
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
is there for the DMDFE AST.
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
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable scorn wrote:Am 06.01.2011 20:20, schrieb Iain Buclaw:=3D=3D Quote from scorn (scorn d.net)'s articleAm 05.01.2011 21:24, schrieb Iain Buclaw:=3D=3D Quote from Scorn (scorn scorn.net)'s articleI too wonder how much work it would be to support OpenMP in gdc. Fr=
http://www.drdobbs.com/high-performance-computing/226300277 it seems to be
there is also quite a lot of magic on the compiler side (but which could
be in the gcc parts). Maybe a concurrent garbage collector would also be
(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
support for multicore programming in one way or another will be rea=
importantfor 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=
parser/internal codegen functions. So to start, will need to rewrite=
half of
is there for the DMDFE AST.
mailing list (whatever this is (d.learn ?)) for discussion. While thi=
might at first be a gdc only solution, having a general, developer approved official D syntax for all three compilers (dmd, gdc, ldc) wo=
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
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=
extension of the Microsoft Parallel FX Framework (see: http://pietschsoft.com/post/2007/09/Parallel-FX-Library-Optimize-your-c=
for example). =20
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
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 articleAm 05.01.2011 21:24, schrieb Iain Buclaw:== Quote from Scorn (scorn scorn.net)'s articleI 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
there is also quite a lot of magic on the compiler side (but which could
be in the gcc parts). Maybe a concurrent garbage collector would also be
(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
support for multicore programming in one way or another will be really
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
is there for the DMDFE AST.
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).
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
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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; }
Yes, exactly like that! (Thanks for the hint.) =20It 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_=
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
On 2011-01-06 20:20, Iain Buclaw wrote:== Quote from scorn (scorn d.net)'s articleAm 05.01.2011 21:24, schrieb Iain Buclaw:== Quote from Scorn (scorn scorn.net)'s articleI 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
there is also quite a lot of magic on the compiler side (but which could
be in the gcc parts). Maybe a concurrent garbage collector would also be
(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
support for multicore programming in one way or another will be really
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
is there for the DMDFE AST.
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
== Quote from Jacob Carlborg (doob me.com)'s articleOn 2011-01-06 20:20, Iain Buclaw wrote:== Quote from scorn (scorn d.net)'s articleAm 05.01.2011 21:24, schrieb Iain Buclaw:== Quote from Scorn (scorn scorn.net)'s articleI 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
there is also quite a lot of magic on the compiler side (but which could
be in the gcc parts). Maybe a concurrent garbage collector would also be
(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
support for multicore programming in one way or another will be really
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
whatis there for the DMDFE AST.
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
pragmas will result in an error.
To be extremely pedantic... yes.
Jan 08 2011
On 2011-01-08 16:34, Iain Buclaw wrote:== Quote from Jacob Carlborg (doob me.com)'s articleWouldn'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









=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> 