William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/5/21 5:42 PM, Kenneth wrote:
> >
> > My own 'working hypothesis' at the moment is that ALL of a scene's code and
> > elements are being duplicated for each 'new' loop, not just any
> > image_maps... and that each loop's 'new' memory use adds to the previous
> > total.
>
> If you get a chance, I'd be interested in a single thread run on your
> machine/windows. I'm actually getting better reported FPS that way than
> using 2 cores / 4 threads - which on the surface doesn't make much sense.
>

I ran a series of thread tests, with the preview display OFF, and got some
interesting and mysterious results.

Running my bare 'cameras only' test scene, and letting the kla/rtr animation run
and loop continuously for exactly one minute:

1A) With:
preview display OFF
1 thread-- Work_Threads=1 in my .ini file
Result: NO increase in used memory(!), although the value dances around a bit as
expected (just a result of the memory being cleared after each loop, I suppose).
About 35MB average
20.5 fps, consistent

1B)
Same as A), 1 thread, but with the preview display ON (800X600 render):
The memory use *increases* to 2050 MB by the 1 minute mark.
16.6 fps, consistent more or less

The 1A) combination of 1 thread and NO display preview is the only one of my
tests where the memory did not increase. Here, the preview display seems to be
the root cause of the increasing memory.

However...
2) Using 2 threads, with preview display still OFF:
Memory use increases to 2040 MB anyway
30.3fps-- but *very slowly* starts climbing, by hundredths of a second

....and every additional thread that's used causes a FASTER memory increase. With
4 threads, it climbed to 11,723 MB! That's as far as I dared to go. So in these
>1-thread test cases, it looks like multi-threading itself is the culprit,
somehow.

(BTW, file output being on or off does not affect any of these results, as far
as I can tell.)

So maybe kla/rtr was never meant to be run in a multi-threaded environment?

-----
BTW: I need to modify my previous comments about the trouble with the 'stop'
button, at least in Windows. It actually *does* work-- but certainly not
immediately *when using more than 1 thread*. In such cases, the looping
animation continues to run for awhile, but only while POV-ray slowly RELEASES
its resulting big memory load. Once the memory value falls to POV-ray's 'idle'
value, the looping animation finally stops. None of this happens when using only
*1* thread, though; the 'stop' button works instantly.

Post a reply to this message