Add color wheel to output

[cbachhuber]

Show a color wheel indicating actor direction in the grid images, as advertised in the README:

Features:

• Wheel can be rotated with an integer parameter (orientation is currently correct)
• Wheel size is relative to original image, given by a float parameter

Considerations:

• I just put all this into main.cpp. I think we can devise a better structure for the new functions and for other free functions in main.cpp. I'm thinking of a utils file. If you agree, I could create a PR with a suggestion for that.

[TheCodez]

This is awesome!

Yes that would be nice. If you want you can also extract the simulator class into its own simulator.h file.

Thank you for all the great work so far 👍

[cbachhuber]

Thank you very much for the kind words! So far, I'm having fun here, also thanks to your support.

Structure sounds good, I'll tackle that in the coming days.

[TheCodez]

Out of curiosity, what execution times do you get on which type of GPU?

[cbachhuber]

Good question! I'm on a Nvidia Quadro P2000, driver 435.21. I think that performance-wise, it's roughly equivalent to a GTX 1050. I see the following execution times of demo on the current master branch:

Parameter modification	Cycle time	Setup duration (until the for loop in main)	overall execution time
none	138-156ms	44s	47s
particle_count = 1*10e5	52-63ms	12s	13s
particle_count = 6*10e4	35-39ms	6.8s	8.4s

I don't see a significant time difference between release and debug, tested with a few runs. I saw a strong influence of particle_count on the execution time of setupRandomStatesKernel when playing around with the code earlier. Is the same true for you? Which executions times do you see? Also, is such a high particle count necessary? When I used lower numbers (>5*10e4), I didn't see (subjectively) worse results.

Since execution time is one of the main motivations of having this project in addition to mitkina/dogma, I would suggest documenting mine and your cycle/iteration times somewhere quickly accessible (in the top-level readme, or in a file linked from it). What do you think?

[TheCodez]

Thanks for the detailed benchmark. I’m seeing similar timings (slightly slower) using a GTX 1050 on my laptop.

I have an idea to improve the random setup time. Overall my goal is to improve the performance to get close to the timings in the paper, from which I‘m still far away considering the amount of particles they use. I hope that switching from AoS to SoA will give a ~3x performance boost.

Yes, the particle count might be too high for this basic scenario and grid Size. I just tried setting the particle count about as high as my system supports (2GB Video ram only). Actually if you set the resolution to 0.1 you‘ll see that the particle count is too low for that grid size.

I will add your timings to the readme plus a comparison with the paper timings/particle count.

[cbachhuber]

I'm looking forward to your setup time improvement!

For the paper, they use a GTX 980, which is more than twice as powerful as our GPUs. Therefore, if you achieve approximately double the cycle time as reported in the paper, you should have an equally optimized algorithm, right? Of course there is still some way to go.

I see, so the particle count is well motivated 👍

Cool; I would also mention the GPU performance difference between the paper and our experiments.

[aquac]

@TheCodez @cbachhuber Sorry for hijacking this PR, but I have a question regarding performance and memory demands I didn't want to create a new issue for that.

Given N_p persistent and N_b birth particles, what is the max. required memory for this implementation?

[TheCodez]

@aquac I’ll check this and get back to you.

[cbachhuber]

I quickly checked this with watch -n 0.2 'nvidia-smi' while letting the demo run, and I see that the demo application requires 130-220MB on the GPU.
This is on the current master, so N_p=3E5 and N_b=3E4.

@TheCodez can you confirm?

[TheCodez]

I need around 290MB using the same numbers.
One should also note that the memory is also highly dependant on the grid size not just the particles. In fact a particle is only 28 bytes whereas a grid cell needs 60 bytes.

[aquac]

@TheCodez @cbachhuber thanks a lot!
One more question, since I didn't dig into the code, is the maximum memory demand determined by (N_p + N_b) or just N_p because the old particles are discarded beforehand?

[TheCodez]

@aquac by (N_p + N_b), they are used until the end and never discarded.