"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:49b3e818$1@news.povray.org...
>
> The problem is basically that the cache is memory-intensive, and 
> allocating
> memory during render is something we really like to avoid, as it requires
> locking; the more threads, the more contention for the lock.
>
> I've just spent some time playing with this and have improved the
> performance somewhat by using memory pools, but it's still not as fast

Anything would be an improvement... this was causing a drastic slowing! But 
what I wouldn't have expected was the AA seemingly triggering it.

I was looking for signs of something in the render stats and at first 
thought it was showing up in the doubling, tripling or more, of numbers 
(rays tested, crackle cache, etc.) when using AA versus without. That is, 
until I realized it's the same way regardless of thread count. Just hadn't 
occurred to me AA alone makes the stat numbers jump.

This thing about memory usage you tell of makes sense to me, even if I don't 
understand the real workings, so I'm just glad to hear there's a reason 
behind this particular slowdown instead of something wrong elsewhere. Yet 
the other slowdowns concerning thread count act like memory trouble, to me 
anyhow, so I'm thinking that would be great if somehow a revelation occurs 
from your work on the crackle fix (wishful thinking or not).

Reading a little about threads and memory pools just now (google searched) 
is interesting, and confusing. Maybe not as problematic as it sounds, eh?
;)

Bob

Post a reply to this message