Well-written parallelised code using C++11 features?

[bythescruff]

Hi folks.

I'm about to evaluate an implementation of SYCL for ease of use and performance when writing parallel programs for heterogeneous environments, and I'm looking for good candidate programs to port to SYCL which will exercise its C++ features.

Can anyone suggest any good examples of open source libraries or applications which are highly paralellised and which are written in "modern C++"? I'm particularly interested in code which uses (or could well use) lambda functions and variadic templates, but anything which makes good use of templates, smart pointers, RAII, STL, and exceptions would be interesting.

Thanks in advance.

[OReubens]

things that come to mind...

- Fractal image calculation
- monte carlo simulations
- massively "big int" implementations (thousands of bits) and calculations based on those.
- prime testing, and related subjects like Factorization, and cryptography
- Fast fourier transforms
- image and sound compression
- raytracing and radiosity rendering
- conway's game of life and all it's variants
- anything typically used in distributed/grid computing

[razzle]

Can anyone suggest any good examples of open source libraries or applications which are highly paralellised and which are written in "modern C++"? I'm particularly interested in code which uses (or could well use) lambda functions and variadic templates, but anything which makes good use of templates, smart pointers, RAII, STL, and exceptions would be interesting.

I doubt you will find such applications at this point. Most existing applications are not "highly parallelized" and the few who are are neither "well-written" nor using "modern C++".

So while finishing up the SYCL implementation I suggest you also write a set of synthetic test cases that resemble what you would be likely to find in real code if it existed, and then rewrite them using SYCL.

I suppose SYCL is an attempt to unify the CPU and the GPU from the perspective of the C++ programmer right?. NVidia already has coined a term for that and anybody who's into parallel computing knows it's called Unified Memory. So all you have to do to sell SYCL is to say it's Unified Memory for OpenCL. Rather than evaluating SYCL in isolation I suggest you benchmark it against nVidia's offering.

[OReubens]

unified memory has not much to do with parallell computing per se. That's just about a better means to share resources between the videocard and the system. of course parallel computing will benefit from that as well.
I'm as of yet unconvinced on this, all other previous attempts over the years at unifying video and system memory have failed, the needs and requirements of videomemory and system memory are not identical enough, so you either end up with someting that'll be more expensive, or something that'll be less performant, there's a reason why videomemory and system memory tend to be separated on machines where performance matters.

nvidia's GPU framework for using the GPU's is CUDA, AMD has GCN. OpenCL is supposed to be the open framework that handles everything (and non GPU FPGAs), but atm it's highly influenced by CUDA.

AFAIK, there is no current framework that would allow you to write a single set of code that would be parallelized over the CPU AND the GPU simultaneously, you can certainly do that if it would be advantageous, but you'ld need code for either side.

You're right in asserting that "most applications are not highly parallellized", this is just the nature of the beast, parallellizing is a very specific (and limited) case scenario so it doesn't fir "most programs". In fact I can even go further and say that most applications aren't even (really) properly multithreaded. Sure some make extra threads for stuff, but apps where a significant part of the calculation is shared over available CPU cores is a minority as it is. The feasibility set for parallelization is even smalller.
That doesn't mean there are no well written and highly parallelized apps out there, but as would be expected, they are all extremely "niche".

I already pointed out the most Obvious usage cases in #2.
have a look here for more detailed usage case descriptions
http://streamcomputing.eu/blog/2013-...l-can-be-used/

[razzle]

AFAIK, there is no current framework that would allow you to write a single set of code that would be parallelized over the CPU AND the GPU simultaneously,

Well, as I said nVidia is working on it with their Unified Memory concept,

http://devblogs.nvidia.com/parallelf...ory-in-cuda-6/

And Khronos is playing catch-up with SYCL it seems.

https://www.khronos.org/opencl/sycl

I already pointed out the most Obvious usage cases in #2.

Only the OP asked for real code written in a certain way.

[OReubens]

Well, as I said nVidia is working on it with their Unified Memory concept,

http://devblogs.nvidia.com/parallelf...ory-in-cuda-6/

And if you have actually read it, you would have seen that it's about sharing/unifying system and video memory. This has NOTHING to do at all with running "the same" code in parallel on both the CPU and the GPU cores.

it's about lowering the bar to new devs to allocating and managing video memory needed for the GPU cores and speeding up system to/from video memory copying (by no longer needing to copy).

Only the OP asked for real code written in a certain way.

which isn't going to work very well.
Code where parallellizing is implemented well will be highly tuned and highly task specific. Trying to turn that into test cases or benchmarks will be very difficult.

It's better to create "generic" and simplified test cases, then run these as regular single core, multicore, and openCL (and/or SYCL) based.

[razzle]

And if you have actually read it, you would have seen that it's about sharing/unifying system and video memory. This has NOTHING to do at all with running "the same" code in parallel on both the CPU and the GPU cores.

It certainly has. Try it out and you'll understand.

which isn't going to work very well.

I know and that's what I told the OP when I saw your irrelevant "mind-list" reply.