[sparsh0mittal]

Both serial and parallel versions of code of red-black SOR (successive over-relaxation) method in three state-of-the-art languages, viz. Chapel (from Cray Inc.), D (also called dlang, from Digital Mars) and Go (also called golang, from Google) can be downloaded for academic use from this link https://www.academia.edu/9709444/Sou...d_Go_Languages .

These codes have been used in this paper https://www.academia.edu/3982638/A_S..._HPC_Languages .

[wyldckat]

Greetings Sparsh Mittal and welcome to the forum!

I hate to have to say this, but there are few details that gives me some suspicion regarding the quality of the results you've achieved:

1. In Table 1, the speed up calculation for Chapel with 8 threads is clearly wrong. I didn't do the math, but the Chapel build was clearly faster than the Go build, and yet the the speed up factor is a lot smaller, as shown in the figure below:
   
   • edit: Sorry, I didn't notice that the reference serial executions were so different as well.
2. The specific hardware used was not specified. Whether you may like it or not, the exact model of CPU and the memory set-up used can influence greatly on the results.
3. Comparing the results to C++ code would have been nice, and possibly Python as well, since otherwise this is just comparing shiny programming languages... although I guess that the Chapel code is the one closest to C++ code.

Originally you had posted this on the Hardware forum, so I moved it to the Lounge forum, since it was off-topic for the other forum.

Best regards,
Bruno

[sparsh0mittal]

Originally Posted by wyldckat

[*]edit: Sorry, I didn't notice that the reference serial executions were so different as well.

Thanks. As you yourself noted in the edit, the baselines used are also different, so the results are fully correct.


As for the servers used, I ran the experiments when I was at Iowa State. We had departmental servers http://it.engineering.iastate.edu/remote/ and I ran the experiments on those with 24 cores (note that this link is very frequently updated to show the servers which are online). Now I have moved from there and don't have access to those servers.

This paper is intended as a study of emerging HPC languages and not necessarily a thorough evaluation of their performance and comparison with other languages. Since the source-codes have been made available, it will really interesting to see if others extend the work by comparing with more languages.

[wyldckat]

Many thanks for clarifying this!

I didn't notice that the source code was also available... any chance you can upload this to a repository in https://github.com or https://bitbucket.org or any other similar free service? Because it makes it a lot easier to analyse and collaborate in source code on these kinds of repositories

Then if the machine you used had at least 8 real cores and not using HyperThreading or similar, than the performance should have been near optimum.

Either way, this looks like an interesting algorithm to implement in benchmark software... namely for having a quicker and efficient way to properly diagnose how CPUs+RAM will perform, without having to install a massive CFD toolbox to do such tests.

[sparsh0mittal]

Thanks Bruno.
Regarding uploading to github, I am presently involved in other projects and hence, would not be able to myself lead collaborative-development of it in other languages. However, if anyone else can lead this, I can put this code on github and he can coordinate further development and allow new additions etc.
I have shared the code with Chapel, D and Go developer communities also.

Regarding performance, I also think, it scales much less than expected. The reason is that SOR is not embarrassingly parallel. It has serial phases, e.g. condition check for convergence. Also, from processor point of view, when the number of cores increase, the remaining resources of memory such as cache and main memory do not increase linearly and hence, the increase in speedup is not linear.

[wyldckat]

Hi Sparsh,

Don't worry about having to lead the development. If you put the code in Github along with the necessary license file, the terms of redistribution and how collaboration can be done (in your case, you would state "feel free to fork and take the lead in continuing development"), then Github already offers the infrastructure for anyone to fork and collaborate, even if a "pull request" is never done.
And since "forks" are automatically kept tracked of, it'll be fairly simple for anyone to check who is working on what

edit: CFD software isn't always embarrassingly parallel, which is why this would also be good as a benchmark example. The objective would only be to have a basis of comparison, because there are very few benchmarks out there for CFD and many are never conducted in the same exact way .

Best regards,
Bruno

[sparsh0mittal]

Sure. I will put it to github today and share the link here.
PS: Would you please shift this thread to Hardware or some other more relevant forum. I think, since the code is also available, it relates to CPU and it may be useful for other researchers.

[sparsh0mittal]

The codes have been made available for non-profit academic/research use at the following github repository.

https://github.com/sparsh0mittal/sor...parallel_codes

Comments are welcome.

[wyldckat]

Originally Posted by sparsh0mittal

PS: Would you please shift this thread to Hardware or some other more relevant forum. I think, since the code is also available, it relates to CPU and it may be useful for other researchers.

Haven't moved it yet to the Main CFD Forum, which is likely where it's more applicable, because I'm still waiting for feedback from the forum admins.

edit: Have gotten confirmation from the admins to move this to the Main CFD Forum and it's now moved!