Do you think this one AMD EPYC 7702 64-Core 2.0GHz (3.35 GHz Max Boost) or this oneIntel Core i9-7980XE X-Series Extreme Edition 2.6 GHz 18-Core LGA 2066 is faster?
GPU simulations will be good to have. Would it be good to have them at the expense of bugfixes and new features though? Will ping you when there is something, and it’s important to know that there is interest and hope for GPU simulations to turn things around. Two years ago, there was so much we could optimize on CPU for simulations, that it was obviously worth the effort, so we did it and now a Phoenix 3.99 simulation is significantly faster than a Phoenix 3.00.01 simulation on CPU. There are still at least 2 more large algorithms we could optimize significantly, so CPU sims can get faster even without changing the hardware.
I could not tell you any more about these two CPUs than what we’ve put on the docs site’s Hardware Advice section, so if anyone has any first-hand experience with them, please do share
Well we changed 10 core 7900x with 18 core 9980xe and it is slow in simulations. It went from 1.32m vox/s to just 1. I am shocked. it has almost twice more cores.
we also tried limit cores from 18 to 10 and the speed is the same. And overclocked it to 4.2 ghz
I also noticed core speeds are very jumpy from 4200 to 1600. I attached the video. I remember old phoenix used to use 100% of cpu without any jumping. Maybe a bug?
all these tests were done with fire and smoke. We havent tried liquid yet jumpy.zip (733 KB)
I did another test it’s just lots of smoke in the box using direct smooth. It keeps CPUs at 100% When I use buffered smoke it is way slower and cpu is not at 100% I know buffered is harder to calculate but why not 100%
The bottle neck of Phoenix is the RAM speed, not the calculations. Actually, this is true for big amount of contemporary software, just the working frequency is so big, that the memory appears like an “external device” to the processor. So, with this in mind, faster RAM and bigger cache is better than multiple cores. This also answers to you question why buffered is lower - as the name says, the buffered method requires a “buffer”, one more piece of RAM involved in the calculations. The direct method is working directly with the velocity data, no buffer is involved, thus having lower buss usage.
I am on 9940 i9 and speed simulation vary from 20-50%. This is on default fire preset. Maybe it is how it suppose to be but am having similar results as I had from amd 1950x which is NUMA…
Hey guys, since we don’t have these CPUs here it would be very useful if you can send over your Phoenix logs from these simulations, so we can see how they compare with our setups.
Hey @cb_LLC , indeed all grids go into one log. Unfortunately this seems like a log from a Max session run that contains only rendering and no simulation. Would it be possible to simulate the scene you sent over and grab the log file right after this is done?
Hey, checked the log - the simulations that you’ve run range between 1-2 million voxels and take about 2-4 seconds per frame. The conservation phase for this setup takes up a huge portion of the simulation time. If you are using the Buffered method, it’s quite dated and has many issues, so I’ve been on the line of completely removing it from Phoenix for years now - if it does not scale well, this just adds up to its other issues. A small simulation like this would also poorly utilize the CPU because it starts and stops all the time - reading the scene from 3ds Max at each simulation step, writing the cache files, updating 3ds Max’s viewport preview… There definitely is a lot of room for improvement in such simulation, but in order to utilize the CPU better, a larger simulation would be better. Running the Fire preset on my machine load the CPU on average at about 70%, so if it’s lower on your machine, then it really sounds like bad scaling of this particular setup indeed - I’m running an i7-6800K @ 3.4 and write the caches to an SSD.
Would be interesting to know how larger simulations performs on your machines, e.g. 50M voxels or more. There would also be differences in scaling between FLIP and grid simulations. Will run some tests on machines here in the office as well.
@cb_LLC , I run your ‘cpu 50 max.max’ scene here and my CPU was at at about 90%. From your video I see that your bus speed is 100MHz, just like mine, so my current guess is that the CPU is starving for data and cannot get fluid grid data quickly enough in order to start processing it.
My log file says that in this particular scene it’s again the conservation step that takes by far the longest time, which is using the Buffered method as well, so it’s really interesting how the other conservation methods perform both your machines. Can you guys try changing to a PCG and Direct Symmetric and share logs or observation if there is any visible difference in CPU load?
I have send phoenix log sent (support ticket no. 158-855-9382). One of the presets (fd_fire) with over 100 millions cells. The use of cpu were much better but not consistent, but the reason of that was explain in your previous post. I am not sure where to find the option to switch the buffer off but as I said need to spend more time with Phoenix.