POV-Ray : Newsgroups : povray.binaries.programming : An updated povr tarball for Unix/Linux. f6b1c13e : Re: An updated povr tarball for Unix/Linux. f6b1c13e Server Time
5 May 2024 00:24:17 EDT (-0400)
  Re: An updated povr tarball for Unix/Linux. f6b1c13e  
From: William F Pokorny
Date: 3 Aug 2020 09:40:01
Message: <5f2813b1@news.povray.org>
On 8/2/20 7:33 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 7/29/20 2:16 PM, jr wrote:
>> ...
>> regarding that, I did a
>>> 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
>>> call (including surrounding conditional) the only thing that would need to be
>>> added to allow the _f9bc4ef7 version to function safely wrt X11?
>>
>> As safely as the newer release, yes.
>> ...
> 
...
> 
> another "interesting" thing is the output of 'ps'.  a big difference in the
> virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
> while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
> reads 1.
> 

Thank you for information on parsing and render times! I welcome all the 
feedback.

The 2% of normal POV-Ray memory use is surprising/unlikely as is the 1 
thread - given the actual results.

First the obvious, might you have been looking at 'povr' the script and 
not the real running povray command? Otherwise I'm not completely sure.
Something with animation perhaps. Animations do drop back to one thread 
when parsing and memory use would drop there too - initially.

If using photons, the thread use is different in that phase too.

Mostly these days I use top (linux) or htop (Raspberry (now with 8gb 
models and a promise of a true 64bit OS!)). For an artificially long 
running biscuit scene, I do see smaller sizes with top when using -y x11 
- which is not too surprising.

Virtual memory(a) KiB
     1120456 -> 754484 ---> -32.66%
Real memory
      47576  ->  32372 ---> -31.96%

(a) - always a little 'wide' of the mark in my experience.

In news to me. When I look at threads specifically with 'ps -eLf | grep 
povr' I do see a difference between SDL1.2 (v38) and SDL2.0 (povr) in 10 
to 14 active threads on my 2 core 4 thread machine. For me, POV-Ray 
proper normally runs with 10 threads in the final render phase. Six of 
threads are mostly idle. For reasons unknown to me, SDL2.0 has 4 more 
mostly idle threads? A question for the 'someday-maybe look at it 
further' list. :-)

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.