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?)

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.

== 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.

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 ...

== 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

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).


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 ? ;-)

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;
}

	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
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

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

== 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.

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