On 14.02.10 03:30, Ken Willmott wrote:
> Thanks for the comments... there are good suggestions there. I prepared a test
> file so that any of you could try it out. I verified that both OS and beta are
> running 64 bits. I discovered that there are problems even with radiosity
> commented out. Namely, CPU usage is not 100%, and control does not come back to
> the GUI after the render is complete.

The low CPU usage is likely related to the use of crackle, which requires 
some data to be shared between threads. This in turn creates dependencies 
between render threads. The performance of multi-threaded ray tracing 
exclusively depends on the independence of render threads.

Since crackle also happens to be one of the less suitable functions for 
integration performed to render it is an isosurface, it takes very long time 
to find intersections with the isosurface involving a real lot of crackle 
pattern evaluations. The POV-Ray statistics likely show this.

Freeing memory in this state, for various reasons, may also take quite some 
time. Again, the statistics may provide some indication on what is going on.

	Thorsten, POV-Team

Post a reply to this message

When I removed the crackle function from my main project, all the problems
disappeared. Memory remained stable, slightly less than 2.0GB. It will be a
painful loss, since it made such beautiful rock surfaces. I guess I will end up
using something like bozo+wrinkles instead.

It is my impression that virtual memory is useful mostly to make memory
management easier, rather than to increase the working memory capacity. It can't
work with 100% physical memory allocated because of excessive disk swapping. I
think this is a fundamental constraint that is common to all OS, whether it is
Windows or Linux or whatever.

So, in this case, the issue is only that what should have only been a painfully
slow render in physical memory, which some users might have found an acceptable
price to pay for a certain effect, became instead a full-blown failure of the
OS. If there is some way in that case, to limit the expansion of memory or exit
with an error, it would probably be better.

I also realize that with beta versions, the development issues are diverse and
priority is correctly given to primary design features above error and UI
issues.

Thanks, everyone for the help! I can now continue with my project, and I have
other radiosity questions which I will move to the other newsgroup.


Thorsten Froehlich <tho### [at] trfde> wrote:
> On 14.02.10 03:30, Ken Willmott wrote:
> > Thanks for the comments... there are good suggestions there. I prepared a test
> > file so that any of you could try it out. I verified that both OS and beta are
> > running 64 bits. I discovered that there are problems even with radiosity
> > commented out. Namely, CPU usage is not 100%, and control does not come back to
> > the GUI after the render is complete.
>
> The low CPU usage is likely related to the use of crackle, which requires
> some data to be shared between threads. This in turn creates dependencies
> between render threads. The performance of multi-threaded ray tracing
> exclusively depends on the independence of render threads.
>
> Since crackle also happens to be one of the less suitable functions for
> integration performed to render it is an isosurface, it takes very long time
> to find intersections with the isosurface involving a real lot of crackle
> pattern evaluations. The POV-Ray statistics likely show this.
>
> Freeing memory in this state, for various reasons, may also take quite some
> time. Again, the statistics may provide some indication on what is going on.
>
>  Thorsten, POV-Team

Post a reply to this message

"Ken Willmott" <ken### [at] rogerscom> wrote:
> When I removed the crackle function from my main project, all the problems
> disappeared. Memory remained stable, slightly less than 2.0GB. It will be a
> painful loss, since it made such beautiful rock surfaces. I guess I will end up
> using something like bozo+wrinkles instead.
>
> It is my impression that virtual memory is useful mostly to make memory
> management easier, rather than to increase the working memory capacity. It can't
> work with 100% physical memory allocated because of excessive disk swapping. I
> think this is a fundamental constraint that is common to all OS, whether it is
> Windows or Linux or whatever.


You mentioned having quite a bit of RAM.  Have you tried turning virtual memory
off and using a RAM disk to see how it does?  RAM disks are not difficult to set
up, and it may be worth the effort.

-Reactor

Post a reply to this message

On 14.02.10 20:47, Reactor wrote:
> You mentioned having quite a bit of RAM.  Have you tried turning virtual memory
> off and using a RAM disk to see how it does?

Given that turning virtual memory off is impossible in Windows that seems 
like an odd suggestion...

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Given that turning virtual memory off is impossible in Windows that 
> seems like an odd suggestion...

Turning virtual memory off in Windows is trivial. I don't think you can turn 
off virtual addressing, but that shouldn't have an impact on this problem.

Control panel->System->Advanced->Performance->Advanced->No page file

Admittedly, it's behind two "advanced" tabs, but the help tells you how to 
get there too if you put "virtual memory" into the search bar of the control 
panel.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> "Ken Willmott" <ken### [at] rogerscom> wrote:
> > When I removed the crackle function from my main project, all the problems
> > disappeared. Memory remained stable, slightly less than 2.0GB. It will be a
> > painful loss, since it made such beautiful rock surfaces. I guess I will end up
> > using something like bozo+wrinkles instead.
> >
> > It is my impression that virtual memory is useful mostly to make memory
> > management easier, rather than to increase the working memory capacity. It can't
> > work with 100% physical memory allocated because of excessive disk swapping. I
> > think this is a fundamental constraint that is common to all OS, whether it is
> > Windows or Linux or whatever.
>
>
> You mentioned having quite a bit of RAM.  Have you tried turning virtual memory
> off and using a RAM disk to see how it does?  RAM disks are not difficult to set
> up, and it may be worth the effort.
>
> -Reactor

I see very little disk activity during rendering, basically just the output file
being written to. I really don't think disk I/O is a significant bottleneck, but
it is interesting to consider how I might use it for other applications.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Thorsten Froehlich wrote:
> > Given that turning virtual memory off is impossible in Windows that
> > seems like an odd suggestion...
>
> Turning virtual memory off in Windows is trivial. I don't think you can turn
> off virtual addressing, but that shouldn't have an impact on this problem.
>
> Control panel->System->Advanced->Performance->Advanced->No page file
>
> Admittedly, it's behind two "advanced" tabs, but the help tells you how to
> get there too if you put "virtual memory" into the search bar of the control
> panel.
>
> --
> Darren New, San Diego CA, USA (PST)
>    Forget "focus follows mouse." When do
>    I get "focus follows gaze"?

Interesting, I had no idea this was possible. Actually though, I believe it is
probably better to leave it alone. It's probably there to allow better real-time
performance for time critical apps.

Post a reply to this message

On 14.02.10 21:44, Darren New wrote:
> Thorsten Froehlich wrote:
>> Given that turning virtual memory off is impossible in Windows that
>> seems like an odd suggestion...
>
> Turning virtual memory off in Windows is trivial. I don't think you can
> turn off virtual addressing, but that shouldn't have an impact on this
> problem.
 >
> Control panel->System->Advanced->Performance->Advanced->No page file

No, that does not turn of virtual memory, it turns of the page file. The 
page file is part of the a common virtual memory implementation, but the 
most important part is that you have a non-linear physical memory (hence the 
"virtual" in "virtual memory"). In effect, disabling the page file simply 
means the system cannot move writable memory out to disk. The system still 
can move all read-only memory to disk, such as code and static data (i.e. 
resources) loaded from application and library files.

	Thorsten

Post a reply to this message

On 14.02.10 22:00, Thorsten Froehlich wrote:
> On 14.02.10 21:44, Darren New wrote:
>> Thorsten Froehlich wrote:
>>> Given that turning virtual memory off is impossible in Windows that
>>> seems like an odd suggestion...
>>
>> Turning virtual memory off in Windows is trivial. I don't think you can
>> turn off virtual addressing, but that shouldn't have an impact on this
>> problem.
>  >
>> Control panel->System->Advanced->Performance->Advanced->No page file
>
> No, that does not turn of virtual memory, it turns of the page file. The
> page file is part of the a common virtual memory implementation, but the
> most important part is that you have a non-linear physical memory (hence
> the "virtual" in "virtual memory"). In effect, disabling the page file
> simply means the system cannot move writable memory out to disk. The
> system still can move all read-only memory to disk, such as code and
> static data (i.e. resources) loaded from application and library files.

What is even more surprising is that it is even explained on Wikipedia 
fairly well, so before this starts some argument I will post the link:
<http://en.wikipedia.org/wiki/Virtual_memory>

	Thorsten

Post a reply to this message

> Turning virtual memory off in Windows is trivial. I don't think you can turn
> off virtual addressing, but that shouldn't have an impact on this problem.

I have experienced this with XP (32bit) and 4Gb ram.  The PC ran well for around
4 days and then started crashing on start up.  the only way to get it to boot
successfully was to re-enable the virtual memory.

I thought about running a RAM disk but as my PC was failing to boot properly I
assumed that the RAM disk might not initialize early enough to be of use.

Post a reply to this message