https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages

anon:

> https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages

Thank you for the link, it's very uncommon to see papers that use D. But where's the D/Go/Chapel source code? What's the compiler/version used? (When you do floating point benchmarks there's a huge difference between LDC2 and DMD).

Bye,
bearophile

Am Fri, 21 Nov 2014 21:29:09 +0000
schrieb "anon" <anonymous@gmail.com>:

> 
> https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages

Did they upload the source code and input data somewhere?
It looks like Chapel and D scale badly with number of threads
while Go makes excellent use of CPU cores and while executing
slower beats the other two @ >= 8 threads.

Then again they could have had much higher speed if they used a GPU driven approach.

-- 
Marco

On Friday, 21 November 2014 at 21:29:10 UTC, anon wrote:
>
> https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages


 Here is another where they compare Chapel, Go, Cilk and TBB.
http://arxiv.org/pdf/1302.2837.pdf

 Conclusion: TBB is the best..

On Friday, 21 November 2014 at 21:53:00 UTC, bearophile wrote:
> anon:
>
>> https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages
>
> Thank you for the link, it's very uncommon to see papers that use D. But where's the D/Go/Chapel source code? What's the compiler/version used? (When you do floating point benchmarks there's a huge difference between LDC2 and DMD).
>
> Bye,
> bearophile

The flags make it likely that DMD was used (-O -inline -release). IIRC there were some problems with DMD that made it not perform too well in these types of benchmarks that use std.parallelism. Results would likely have been noticeably better with GDC or LDC.

Kapps:

> The flags make it likely that DMD was used (-O -inline -release).

But I use ldmd2 all the time with those arguments :-)

Bye,
bearophile

On Fri, 2014-11-21 at 22:57 +0000, Kapps via Digitalmars-d wrote:
> On Friday, 21 November 2014 at 21:53:00 UTC, bearophile wrote:
> > anon:
> >
> >> https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages
> >
> > Thank you for the link, it's very uncommon to see papers that use D. But where's the D/Go/Chapel source code? What's the compiler/version used? (When you do floating point benchmarks there's a huge difference between LDC2 and DMD).
> >
> > Bye,
> > bearophile
> 
> The flags make it likely that DMD was used (-O -inline -release). IIRC there were some problems with DMD that made it not perform too well in these types of benchmarks that use std.parallelism. Results would likely have been noticeably better with GDC or LDC.

Sorry, I must have missed this thread earlier, hopefully I am not late ;-)

From a quick scan there appears to be no mention of how many cores on the test machine. Maybe there were only 4?

Hopefully they were using ldc2 and not dmd.

I suspect they we using gc and not gccgo.

The words used about the implementations imply there could be a lot better realizations of their algorithms in the three languages. Without actual code though there is very little to be said. I believe it should be a requirement of academic, and indeed non-academic, publishing of any work involving timings that the code be made available. Without the code there is no reproducibility and reproducibility is a cornerstone of scientific method.

On the upside using Chapel, D and Go shows forward looking. I wonder about X10 and C++. Not to mention Rust, Java, Groovy, and Python.

I have emailed the author.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Yes, I'd be curious to see the code.  I also suspect that the functionality in core may not be sufficiently advertised.  At one point he mentions using yieldForce to simulate a barrier, which suggests he wasn't aware of core.sync.barrier.

On Sat, Nov 22, 2014 at 7:17 AM, Russel Winder via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> I have emailed the author.
>

Keep us posted!

This prompted me to google for recent academic papers on D, which
led me to this:

http://research.ijcaonline.org/volume104/number7/pxc3898921.pdf

not exactly the most rigorous research, but it's pretty
favorable...