[deleted]
Optimizing the Particle Life: From 400 to 4M particles
11–20 of 71 posts
Re: Optimizing the Particle Life: From 400 to 4M particles
#12This is pretty neat... Having an interest in the space for many years (on-and-off; life gets busy sometimes) - I've often lamented the lack of good pixel-level performance optimizations in graphics cards. Everything seems hell-bent on polygons. Some years ago, DirectDraw on Windows was an excellent way to optimize the graphics portion of these types of things, but that all went away as "3D Is The Way" mentality took…
There's no lack of "pixel-level performance optimisations" on GPUs, and just because basically the whole world seems to think that graphics programming == using some rasterisation library like OpenGL or DX or Vulkan or whatever for realtime applications, doesn't mean you're forced to use it or that that's all there is.
Just fire up OpenCL (or CUDA, if you must) and start executing some data-parallel kernels.
Re: Optimizing the Particle Life: From 400 to 4M particles
#13This is fairly trivial stuff with underwhelming results. 4 million particles isn't much on modern hardware, even with spatial partitioning. The hardest part of spatial partitioning is probably the one dimensional partition algorithm in the first place, which can be found here: https://en.cppreference.com/w/cpp/algorithm/partition
[deleted]
Re: Optimizing the Particle Life: From 400 to 4M particles
#14Why was C slower though?
Simply compiling it with -O3 produces something which completes in half the time of the JavaScript version (350ms for C, 750ms for JS), so perhaps that. Edit for Twirrim: on this system (Ryzen 7, gcc 11): "-O3": 350ms; "-O3 -march=native": 208ms; "-O2": 998ms; "-O2 -march=native": 1040ms. Edit 2: Interestingly, changing the C from float to double produces a 3.5x speedup, taking the time elapsed (with "-O3 -march=nati…
For fun and frolics:
No flags: 1843ms
-march=native: 2183 ms
-O2: 423 ms
-O2 -march=native: 250 ms
-O3: 425 ms
-O3 -march=native: 255 ms
O3 doesn't seem to be helping in my case.
Re: Optimizing the Particle Life: From 400 to 4M particles
#15Since I’m on my phone, I can only try the 2D js versions, but the quadtree version does seem to provide some really obvious and nice frame rate improvements. It seems like good work, although I don’t know much about this field.
Sidenote:
I’m often too self conscious to put anything technical online with my real name on it, probably a bit of imposter syndrome or something. I think based on
> For one of my programming classes this semester, my task was writing a program in Python. It was only an introductory course, so it didn’t have to be anything fancy.
the author is sort of early on in their career. I often suspect I’d be better off if I’d gotten over myself and thrown more early experiments online. I dunno, maybe this stuff just isn’t a big deal for some people, but I have to applaud the bravery.
Re: Optimizing the Particle Life: From 400 to 4M particles
#16This is pretty neat... Having an interest in the space for many years (on-and-off; life gets busy sometimes) - I've often lamented the lack of good pixel-level performance optimizations in graphics cards. Everything seems hell-bent on polygons. Some years ago, DirectDraw on Windows was an excellent way to optimize the graphics portion of these types of things, but that all went away as "3D Is The Way" mentality took…
The thing you describe as "per-pixel optimizations" is exactly what a fragment shader is? You don't need "a polygon" per say, you can just run said code over ever pixel in the frame for each frame. This is how simple screenspace effects are implemented, compositing, HDR, etc.
Re: Optimizing the Particle Life: From 400 to 4M particles
#174M particles is not the question. what's the framerate?
You can go to the “next” story at the bottom of the post, and then the author has some links to an online implementation.
Re: Optimizing the Particle Life: From 400 to 4M particles
#18Why was C slower though?
Author mentions they didn't use optimization flags but doesn't include the compilation details. You can sort of guess that (relatively) unoptimized C might perform worse than V8's JIT on short, straight computational code - you're more or less testing two native code generators doing a simple thing except one has more optimizations enabled and wins.
Oh, I assumed he still did -O2, and did not do anything else. Is that bad to assume?
PS: I do not use C beyond reading some of its code for inspiration, so kinda unaware
Re: Optimizing the Particle Life: From 400 to 4M particles
#19IMO, not using any optimization flags with C is somewhat arbitrary, since the compiler writers could have just decided that by default we'll do thing X, Y, and Z, and then you'd need to turn them off explicitly. FWIW, without -O, with -O, and with -O4, I get 2500ms, 1500ms, and 550ms respectively. I didn't bother to look at the .S to see the code improvements. (Of course, I edited the code to output the results, othe…
> (Of course, I edited the code to output the results, otherwise, it just optimized out everything.)
O(1) :)
Re: Optimizing the Particle Life: From 400 to 4M particles
#20Earlier quoted context omitted.
Simply compiling it with -O3 produces something which completes in half the time of the JavaScript version (350ms for C, 750ms for JS), so perhaps that. Edit for Twirrim: on this system (Ryzen 7, gcc 11): "-O3": 350ms; "-O3 -march=native": 208ms; "-O2": 998ms; "-O2 -march=native": 1040ms. Edit 2: Interestingly, changing the C from float to double produces a 3.5x speedup, taking the time elapsed (with "-O3 -march=nati…
Did you add output of the results to the C code?
I did not, but I confirmed with objdump that my compiler was not removing the code.
(But to be sure, I just ran it again with an output and got the same value.)