Warp <war### [at] tagpovrayorg> wrote:
>   A "compromise", Don Carlo, actually sounds cool. And with "Don" I don't
> mean the Spanish "sir" title, but the English name (as in Don Johnson).
>
> --
>                                                           - Warp

In fact, at primary schools, my professor called me "Don Carlo",
in honor of the priest *Don Abbondio*, a character of the novel "I Promessi
Sposi" ("The Betrothed" - "Kihlautuneet", for Warp!):

http://en.wikipedia.org/wiki/The_Betrothed_(Manzoni_novel)

In this case, "Don" is a synonym for "priest". :-)

</Off-Topic> (sorry!)

--
Carlo

Post a reply to this message

Bob wrote:
> It *looks* fixed, for me anyhow in the few ways I tried it.
> 
> Render speed is another matter. Without AA the two seem similar enough until 

The problem is basically the crackle cache. The bug before was due to the
cache not working properly. The slowdown now is due to the performance of
the cache now that it is working (a different caching method is used).

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 as
just not using the cache at all. (By that, I mean in wall clock time; using
no cache at all renders faster in terms of waiting for a render if you have
several cores, but burns more CPU time because of the lack of a cache).

It's a difficult problem to solve cleanly. I'll have another stab at it in
a few days.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> It's a difficult problem to solve cleanly. I'll have another stab at it in
> a few days.

  I have no idea how the crackle cache works or what it does, but I was
thinking: Could the crackle cache contents be somehow precalculated prior
to rendering, similarly to how eg. photon maps are?

-- 
                                                          - Warp

Post a reply to this message

Chris Cason wrote:

> It's a difficult problem to solve cleanly.

If synchronization between threads costs more wall clock time
than the benefit of reusing cache data across threads, it might
be a solution to give each thread its own cache. But I don't
know how the crackle cache works in detail so this might
not be feasible after all.

Post a reply to this message

"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

Warp wrote:
>   I have no idea how the crackle cache works or what it does, but I was
> thinking: Could the crackle cache contents be somehow precalculated prior
> to rendering, similarly to how eg. photon maps are?

The problem is the we don't know in advance how large it will be or what
blocks to calculate.

-- Chris

Post a reply to this message

Christian Froeschlin wrote:
> If synchronization between threads costs more wall clock time
> than the benefit of reusing cache data across threads, it might
> be a solution to give each thread its own cache. But I don't

This is not the issue; in fact, each thread does have its own cache. The
problem is that the old code caused memory allocation to happen at run-
time, and this memory came from the global heap. This requires locking.

I made some improvements by using a memory pool for the local storage (==
less calls to new/malloc), but this needs further work. Basically we need
to drastically reduce the number of times we get memory from the global
heap, while at the same time trying to avoid getting too much memory at any
given time (which may not be needed).

-- Chris

Post a reply to this message

On 3/8/2009 7:02 PM, Chris Cason wrote:
> Basically we need
> to drastically reduce the number of times we get memory from the global
> heap, while at the same time trying to avoid getting too much memory at any
> given time (which may not be needed).
>
> -- Chris

How much memory are we talking about here?

If memory is allocated in chunks, then maybe a command-line parameter to 
set the chunk size would be useful for testing until an optimum solution 
is found.  Also, this would allow people with more RAM to use larger 
cache sizes as a default, avoiding the penalty completely.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> > Basically we need
> > to drastically reduce the number of times we get memory from the global
> > heap, while at the same time trying to avoid getting too much memory at any
> > given time (which may not be needed).
>
> If memory is allocated in chunks, then maybe a command-line parameter to
> set the chunk size would be useful for testing until an optimum solution
> is found.  Also, this would allow people with more RAM to use larger
> cache sizes as a default, avoiding the penalty completely.

Another option: Allocate chunks of increasing size. Allocated N bytes in total
and they didn't suffice? Then allocate another N bytes next time for a total of
2*N. Still not enough? Go for another 2*N bytes.

This way you can start out small to save memory in case it's not used much
(waste is guaranteed to never be more than 50%), but get out of the "cost zone"
quickly if you really need a lot of it.

Add some "hard deck" if desired to make sure you don't waste 0.9 GB if you
happen to need 1.1GB.

Don't use dedicated pools for particular data structures, but allocate blocks
for generic use, rolling your own (thread local) heap management.


Just a few ideas "out of the blue".

Post a reply to this message

clipka wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> > Basically we need
>> > to drastically reduce the number of times we get memory from the global
>> > heap, while at the same time trying to avoid getting too much memory at any
>> > given time (which may not be needed).
>>
>> If memory is allocated in chunks, then maybe a command-line parameter to
>> set the chunk size would be useful for testing until an optimum solution
>> is found.  Also, this would allow people with more RAM to use larger
>> cache sizes as a default, avoiding the penalty completely.
> 
> Another option: Allocate chunks of increasing size. Allocated N bytes in total
> and they didn't suffice? Then allocate another N bytes next time for a total of
> 2*N. Still not enough? Go for another 2*N bytes.
> 
> This way you can start out small to save memory in case it's not used much
> (waste is guaranteed to never be more than 50%), but get out of the "cost zone"
> quickly if you really need a lot of it.
> 
> Add some "hard deck" if desired to make sure you don't waste 0.9 GB if you
> happen to need 1.1GB.
> 
> Don't use dedicated pools for particular data structures, but allocate blocks
> for generic use, rolling your own (thread local) heap management.

Most of this stuff was already done, it's not as simple as it appears.

That said, try the current test exe.

-- Chris

Post a reply to this message