Let's talk about Fluid Simulation

I just double checked my fluid code (not looked at it in a while) and it turns out I was lying (well, mistaken). It's wired to use a dt of 1/60th of a second but since I can't guarantee 60FPS with higher numbers of particles I clamp the overall framerate to 30FPS (so, effectively, my fluid runs at half speed). There's evidently some timing and tuning stuff to be worked out there, but it looks good on my screen, for now.

It's difficult to say what the current bottleneck is with my sim, except for "all of it". I spent months running a profiler over and over again and tuning stuff, and there's no one part of the simulation that takes noticeably more than any other parts. The engine as a whole is pretty optimal, rendering the fluid is no particular problem, and managing the neighbours lists is pretty optimal, so the main issue is the stuff to calculate densities and to apply forces. It's multithreaded and as optimised as I can get it, but for large numbers of particles it still chews up a lot of CPU horsepower. Perhaps a bit more could be squeezed out by looking into memory cache misses, but it's not easy to profile that (at least with any free/cheap tools I know of) so I've applied every rule of thumb I know of and kept all of the ones that seemed to help (or at least not hurt).

I spent a while working on a version that used CUDA (NVidia's stuff for doing arbitrary maths and physics on a graphics card) which (despite being pretty suboptimal) runs at a much nicer framerate at the expense of making the code even harder to maintain. I'm hoping for widespread adoption and availability of OpenCL so I can get it to work on ATI cards too, but I'm concerned that only high-end cards will be able to run that, unless the manufacturers make OpenCL work on older cards as well.