Incorrect reporting on typrofiler for property transfer?
#1
Hey,

I just came across a weird inconsistency, perhaps someone can shed some light on it. I have a bunch of particles using the property transfer operator, however the profiler is showing some weird results. If you take a look at the pic you will see the property transfer operator took almost 40 sec to complete the sub-operations of the property transfer, yet the final time took 132 sec, more than 3x the length of time. Does anyone know where the extra time is coming from? Even more strange is at some point the property transfer went at the full speed of the sub operators and it was awesome, however i saved and reloaded and now it seems to be going slow again for no reason, i'm pretty stumped. I included the max file in case you want to poke through it. When it was going full speed, the beginning frames calculated MUCH faster and would slow down as more particles accumulated. When its going slow, the whole thing calculates much slower, even on the beginning frames when there isn't very many particles.

I also did a quick test with the property transfer vs a property test (neighbor count) with the same test radius and for some reason the neighbor test was 2x faster than the property transfer. Its operations also took 3x longer than reported in the property test sub operators. Do they use the same method for accumulating the neighbor particles?

Any insight would be great!

Thanks!


Attached Files Thumbnail(s)
       

.rar   ink_mix_profiletest.rar (Size: 36.16 KB / Downloads: 214)
  Reply
#2
The circled functions are the multithreaded functions which iterate over particles and find neighbors. What you're not seeing is the construction of the kdtree, which I guess I forgot to add to the profiler. Often it can be the case that the kdtree takes longer to build than the actual neighbor search, but that's because building it is a sequential process that cannot be threaded. But ultimately the kdtree build time + search time will still be orders of magnitude faster than a brute force search.

I'll do some further profiling to see if I can figure out why Prop Transfer is taking so much longer to build the tree than Prop Test.
  Reply
#3
Ah that makes sense, I figured there were some single threaded operations going on in between operations. I was monitoring my cpu usage and it would spike up and down very consistently.

Update: I have done some more profiling and when i use the property test operator it causes my cpu scheduler to spike up and down like crazy, which is causing my cpu clock frequencies to be consistently lower. Im not sure if its an issue with windows, my bios or tyflow. Is there a way to make tyflow keep the cpu at its full boosted speed even though its a single threaded operation? If i disable the property transfer operator from my flow stack then all my cores get happily pegged at 100%, but as soon as i enable the property transfer my cpu usage becomes super spiky and inconsistent. It also seems to get worse over time as my ram fills up.
  Reply
#4
I did a little more profiling of the Property Transfer functions....turns out a decent amount of time is spent at the end of each time step cleaning up the collected data. I've optimized that part further and in the next build it should be much speedier.
  Reply
#5
Glad to hear it! Thanks! Big Grin
  Reply


Forum Jump: