Optimizing the Particle Life: From 400 to 4M particles
programmingattack.com
Optimizing the Particle Life: From 400 to 4M particles
1–10 of 71 posts
Re: Optimizing the Particle Life: From 400 to 4M particles
#2Why was C slower though?
Re: Optimizing the Particle Life: From 400 to 4M particles
#3Why was C slower though?
No optimization flags could be a big part of the reason.
Haven't looked closely at the code or tried it, but with -O3, -fopenmp and a well-placed pragma the performance could increase many-fold.
Heck, with NVC++ you could offload that thing to a GPU with minimal effort and have it flying at the memory bandwidth limit.
Re: Optimizing the Particle Life: From 400 to 4M particles
#4IMO, 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, otherwise, it just optimized out everything.)
Re: Optimizing the Particle Life: From 400 to 4M particles
#5This 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:
Re: Optimizing the Particle Life: From 400 to 4M particles
#6Why 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=native") to 58ms, or about 12x faster than JS. This also makes what it's computing closer to the JavaScript version.
Re: Optimizing the Particle Life: From 400 to 4M particles
#7Why 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.
Re: Optimizing the Particle Life: From 400 to 4M particles
#84M particles is not the question. what's the framerate?
Re: Optimizing the Particle Life: From 400 to 4M particles
#9Why 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…
Did you add output of the results to the C code?
Re: Optimizing the Particle Life: From 400 to 4M particles
#10This 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 over.
My explorations of Processing.* were neat, but lacked the IDE and library support I like as a developer.