Performance Notes and Tips
This documentation page is a collection of information on topics related to simulation performance.
Yes, it is normal for your CPU to run under 100% usage on average. CPU usage may be low on lower resolution simulations and is generally higher on high resolution simulations. Here are some explanations why the simulator is not running at 100% usage:
- Fluid simulation is very memory heavy problem and memory access is slow compared to how fast your CPU is. In the simulator, there are many threads accessing large amounts of memory at the same time. The CPU threads must occasionally stop calculations and wait for data to be fetched from memory and this is what commonly causes decreased CPU usage in the simulator.
- Some calculations in the simulator are not able to be multithreaded efficiently and must be run on a single core. These sections of calculations create a bottleneck which lowers average CPU usage.
- The simulator may be running with too many threads enabled. It is possible that simulations could slow down from the overhead of running more threads than the simulator can handle efficiently. Some users with certain hardware (e.g. Xeon/Threadripper CPUs) may benefit from simulating with less threads enabled. You may experiment by changing the number of enabled threads in the Domain > Advanced Settings > Multithreading Settings. Try using a lower number of threads such as half the number of threads and test whether you experience a speed-up in baking times.
Many simulations can be optimized for performance and detail by sizing the domain to tightly fit around your fluid effect. See this documentation topic: How large should I make my domain object?
The simulation calculations alternate between single threaded and multithreaded calculations. Single threaded calculation performance depends on high clock speed as well as high single threaded clock speed. Multithreaded performance depends on high clock speed and multiple cores.
A good all around processor for FLIP Fluids simulation baking would would have 4 - 12 cores (or 8 - 24 threads) with a high clock speed as well as a high boosted single threaded clock speed. High clock speed is the most important aspect of a CPU for this type of simulator in terms of performance. After around 12 cores, you will generally start see diminishing returns on performance when adding more cores.
For highly threaded CPUs (such as Xeon/Threadripper), these perform best for large simulations with a lot of fluid that spend greater than 1 minute per frame. For example, large simulations run on the Threadripper 1950X (32 threads) bake at over twice the speed of an i7-7700 (8 threads) in our benchmarks. These types of CPUs are very fast for the multithreaded calculations, but for the single threaded calculations, they don’t perform much quicker than any other CPU with the same clock speed.
Highly threaded CPUs are extremely fast for the multithreaded calculations, but for the single threaded calculations, they don’t perform much quicker than any other CPU with the same clock speed. They also perform very well for running multiple simulations simultaneously when splitting up the threads between simulations.
Related topic: See the Example Scene Descriptions for simulation time comparisons between different CPUs.
Whether you are caching your simulations on a hard drive (HDD) or a solid state drive (SSD) can affect how quickly your simulation runs. The simulator saves simulation files to your HDD or SSD at the end of each frame, and the CPU cannot continue calculations until the files are finished writing. Generally, file write speed on an HDD are much slower than on an SSD and for this reason it is recommended to cache to an SSD if possible.
For large simulations there will be more data to save to your HDD or SSD. The amount of data can often exceed 300 MB per frame for very large simulation. To test write performance for large files on your HDD vs SSD, you can try copying a 300 MB file. If your HDD is taking 5 seconds to copy this file vs 0.5 seconds on an SSD, this time difference can really add up over a large number of frames. 5 seconds spent on each frame for 500 frames adds up to over 40 minutes spent on just writing files!
The FLIP Fluids simulator is not GPU accelerated. As of addon version 1.0.4 (Aug 09 2018), GPU acceleration features using OpenCL have been removed and all GPU methods have been entirely replaced with higher performance CPU methods.
The simulation methods and techniques used in many of our features are not suitable for GPU processing. This is due to the nature of the types of calculations that our simulator runs. Many calculations of these features are not parallelizable enough to benefit from running on a GPU. Some features would benefit from being run on the GPU, however, switching between computations on the CPU and GPU can be slow and harm performance.
At the moment we do not have plans to add GPU acceleration features to the FLIP Fluids addon. We may visit this idea in a future development project separate from the FLIP Fluids addon.
High quality fluid simulations are known to take a long time to compute, but there are ways to optimize your simulation setup to maximize performance.
High quality fluid simulations are known to take a long time to compute, but there are ways to optimize your simulation setup to maximize performance:
- Does your domain have a lot of empty space? Try resizing your domain to fit tightly around your fluid effect to maximize simulation detail and performance. This is the most common problem we see in simulation setups that are running slowly. See this documentation topic: How large should I make my domain object?
- Does your simulation contain a large volume of fluid? More fluid will lead to longer baking times. Reducing the volume of fluid in your domain will help speed up simulation times. Is simulating a deep pool of liquid necessary? Simulating a more shallow body of liquid is a common way to speed up your fluid simulation.
- Do your keyframe/animated objects contain a lot of geometry? Moving objects need to be re-computed every frame and substep of the simulation. If your moving objects contain a lot of geometry, this can greatly slow down simulation. Often we see animated objects that contain way more geometry detail than is necessary. A common workflow in simulation is to use simpler low detail objects for simulation and high detail objects for rendering.
- Are all of the enabled features necessary? Enabling the following features can add a lot to the simulation time
- Mesh Generation Subdivisions - We usually recommend increasing the mesh subdivision level to 1 for a final simulation. This will take longer to generate but will result in a higher detail mesh. If you are just testing your simulation setup, set the subdivisions to 0 to speed up testing and iteration.
- Whitewater Solver - Enabling whitewater simulation can often double the base simulation time.
- Viscosity solver - There is a trick to simulate low viscosity fluids at no extra cost using the PIC/FLIP Ratio setting.
- Surface tension and sheeting solver - These features are usually only applicable to small scale fluid effects. Enabling these features in large scale fluid effects will add a lot of simulation time and the effect on the simulation will often not be very noticeable.
- Are you able to lower your domain resolution? Not all simulation effects need to be incredibly detailed. If you can get away with simulating at a lower resolution, this will help speed up baking.
When any FLIP Fluid objects have the Export Animated Mesh option enabled, the addon will need to export this animation frame by frame. Here are some note on why this process could be taking a long time and tips to resolve these types of issues:
- Does your object need to be exported as an animated mesh? The Export Animated Mesh option is only needed for objects that have animation more complex than than keyframed location/rotation/scale or f-curve animation, such as armatures or parented objects. The addon will be able export simple keyframed animation very quickly.
- Do your animated objects contain a lot of geometry? Excessive geometry can take more time to export. If your exported mesh geometry contains many thousands of vertices and polygons for each frame, this can really add up and take a long time to export! For most cases, 30k faces for an object is more than enough geometry for the simulator. You may want to use the high poly object for rendering and a lower poly proxy version of the object for simulation.
- Don't want to take the time to re-export when starting a new bake? If your animated object has already been exported and the motion hasn't changed, you can skip re-exporting this object by enabling the Skip animated mesh re-export option for the object. Just remember to disable this option, or force a re-export if the motion or geometry of the object has changed since the last export.
- Is playback slow in your scene? To export animated meshes, Blender needs to evaluate and playback each frame in order to fully evaluate the object meshes. If you have other baked data or objects in your scene that take a long time to evaluate, disabling these objects from loading (such as by disabling modifiers) will speed up playback, and thus will speed up animated mesh export.
As the simulation runs, a performance score metric can be viewed in the Domain > Stats > Simulation Stats panel. The Performance Score value is a simple measure for how much fluid is being processed per second on your system under the current simulation setup and settings. This value can be viewed for individual frames or an average over the entire cache.
Notes and Tips:
- The score may range from small single or double-digit values to higher values in the thousands and will depend on your CPU, simulation setup, and simulation settings.
- This score can be used to get an idea for how the current simulation setup is performing on your CPU and how changes to the setup or settings affect performance.
- This value can also be useful for measuring performance at different thread counts. Running small simulations with too many threads can harm performance due to overhead of thread management. For small simulations, you may see a higher performance score and quicker simulation baking at a lower number of threads (Documentation).
As an example, here are the performance score results on a high powered Intel i9-13900K CPU for different thread counts on a basic simulation at the default 65 resolution. As you can see, running this simulation with 4 threads maximizes the performance score while running with the maximum 32 threads results in a lower score.1 thread: 364 2 thread: 590 3 thread: 671 4 thread: 716 <-- 5 thread: 714 6 thread: 672 7 thread: 646 8 thread: 608 16 thread: 417 32 thread: 249 - The performance score may increase for larger high resolution simulations as there is more fluid to process and take advantage of more CPU resources.
- Enabling more addon features will often increase how long it takes to compute the fluid, and in turn will decrease the performance score.
- If the simulation setup contains a domain with a large amount of empty space, this can lower the performance score. Sizing the domain so that it fits more tightly around the fluid effect can help improve performance. Related topic: How large should I make my domain object?