tutorial /getting started

[lslusarczyk]

Copied discussion from slack:

ŁŚ: In order to attract developers to our library I have an idea of creating a sample github repo with well described example of using distributed ranges repo for one application. This is going to be just one example (in one architecture) with cmake importing our project just like client apps are meant to be written.

I expect 'lazy' students/reserchers will find it easy to fork such a repo and modify for their needs. We can possibly see if forks appear and how many forks are there and measure interest this way. Separate repo makes it also clear that customers don't need all the other oneAPI stuff.

(1) What is your opinion on advertising dist-ranges this way?
I think such an example repo should be best placed under github.com/intel url prefix, eg. github.com/intel/gpu-distributed-data-structures-example.
I see that oneAPI-src namespace in github is not used for such a small projects, but intel namespace is, see:
https://github.com/orgs/intel/repositories?q=sample&type=all&language=&sort=

(2) Do you have idea how repo could be named? "distributed-data-structures-example", "gpu-distributed-data-structures-example", "distributed-ranges-sample-application"?
Finally what exacly the example should be? I am thinking of implementing (and describing in our tutorial) "Game of Life" like it is shown in this tutorial https://www.mathworks.com/help/parallel-computing/stencil-operations-on-a-gpu.html I think of implementing it in mhp with sycl and GPU.

(3) What in your opinion could best serve as an attractive example for tutorial and sample application? And in what architecture we should write it?

I like the idea of having an example that demonstrates how DR is meant to be used in external applications. We could however include such miniapps in the main repository itself (some projects also include demos with commentary). Having everything in the same repo also makes it easier to maintain.

Lukasz Slusarczyk
3 months ago
We could however include such miniapps in the main repository itself (some projects also include demos with commentary).
Thanks for the idea.
Problem with separate dir within current repo is that we don't see forks and that staring your own dist-ranges project is not as easy as doing fork. Indeed it is easier for us to maintain.
At least it is worth to start with such a separate dir and then decide whether to move or not when example is ready.
Ideas about a good (potential) repo name are still wecome.

BB: I think this is a good idea. I think we should keep as many examples in the repo as we can, but having a separate repo is also good, as it shows how to set up a project using DR as a dependency
We could start by basically copying all the examples into different directories
This would also be a good place to have both Makefile and cmake -based build paths
(Some people, particularly in HPC, are always going to insist on using make)
I have a well-kept and pretty generic Makefile we should include

ŁŚ: Thank you for comments Ben. It is interesting what you wrote about 'make' and HPC By pure make one can not fetch automatically dist-ranges as dependency, I think. But if I'm wrong and we can omit cmake, still fetch all by 'make' command and we can have our sample repo simpler this is good. AFAIR 'makefiles' are not very readable unless they do very trivial builds :(

I'd like not to require user to set up any env variables or download anything manually. I'd like simple sequence of git clone + cmake + make just work, so it is likely one will not need to read any doc to have example running. I think this + simple example code (and simple build code) inside will encourage people to try it and have a look to our examples/doc/code next.

JK: I'm talking to different HPC people. Even Fortran applications use cmake. What is their excuse not using cmake with C++ projects?

RC: We could have a hello world example with a simple makefile in addition to the cmake examples. The set of people who have gcc 13 and do not want to use cmake is small so it would have to assume manual install of ranges-v3. We also need instructions on how to build on a system without an internet connection.

[lslusarczyk]

Example of good getting-started with tutorials: https://legion.stanford.edu/starting/

[lslusarczyk]

Current version of tutorial: https://github.com/mateuszpn/distributed-ranges-tutorial
intel cloud GPUs: https://devcloud.intel.com/oneapi/home/