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

Another test version:

  http://www.povray.org/temp/pvengine-crackle.zip

-- Chris

Post a reply to this message

Chambers wrote:
> 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 

The work I've just done brought me more or less to the conclusion that we
do need a way to allow users to provide performance hints to the renderer.
There are a number of places - particularly crackle cache - where we could
benefit from the user letting the renderer know whether they care more
about memory than speed. It's not really something we can guess in advance.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Most of this stuff was already done, it's not as simple as it appears.

As I said, just a kind of brainstorming. Based, to be honest, not on my
knowledge of the crackle code (which in fact amounts to zero), but on how
memory handling is currently implemented in the radiosity code.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Another test version:
>
>   http://www.povray.org/temp/pvengine-crackle.zip
>
> -- Chris

Grazie!
I will do some tests.

--
Carlo

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Another test version:
>
>   http://www.povray.org/temp/pvengine-crackle.zip
>
> -- Chris

For me, *crackle problem* vanquished.

The performance is (significantly) improved (than 3.6.1)
I am (slightly) puzzled only for crack1.pov, so I will do further tests.

--
Carlo

Post a reply to this message

Carlo C. wrote:
> For me, *crackle problem* vanquished.
> 
> The performance is (significantly) improved (than 3.6.1)

can you advise if the performance is better than 3.6.1 on a single thread? (i.e.
run the the new code with one thread only, assuming you have a SMP machine).

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Carlo C. wrote:
> > For me, *crackle problem* vanquished.
> >
> > The performance is (significantly) improved (than 3.6.1)
>
> can you advise if the performance is better than 3.6.1 on a single thread? (i.e.
> run the the new code with one thread only, assuming you have a SMP machine).
>
> -- Chris

My first computer is died, so I did my tests with "muletto" (a term derived from
Formula One): Amd Athlon 1.4 Ghz and 512Mb RAM.

I don't know how this can be significat test.
Neverhless, I hope I can make myself useful.


--
Carlo

Post a reply to this message

For now...

- Machine: Amd Athlon 1.4Ghz, 512Mb RAM, XP Home SP3 -

--------------------------------------------------------------
[File: ...\POV-Ray\v3.7\scenes\textures\patterns\crackle1.pov]
[   Settings: 1600x1200 pixels noAA -D (five tests)          ]

- 3.6.1 vs. 3.7.31 (with crackle problem):
       3.7.31 faster than 7.0/8.5%

- 3.7.31 (with crackle problem) vs. 3.7.31 (crackle patched):
       3.7.31 (patched) faster than 0.8/3.0%
--------------------------------------------------------------
--------------------------------------------------------------
[File: ...\POV-Ray\v3.7\scenes\textures\patterns\crackle2.pov]
[   Settings: 1024x512 pixels noAA -D (five tests)           ]

- 3.6.1 vs. 3.7.31 (with crackle problem):
       3.7.31 faster than 58.9/60.0%

- 3.7.31 (with crackle problem) vs. 3.7.31 (crackle patched):
       3.7.31 (patched) "slower" than 0.0/0.9%
       (say the same, perhaps this old cpu has overheated!
       :-D)
--------------------------------------------------------------

--
Carlo

Post a reply to this message

I tried a quick test using 640x480 res., crackle1.pov and crackle_form.pov 
(not animated) and got the following.

3.7 beta 31 (fixed crackle) 1 thread:
crackle1.pov
noAA=2.5s; AA=4s

crackle_form.pov
noAA=8s; AA=16.5s

3.7 beta 31 (fixed crackle) 2 threads:
crackle1.pov
noAA=1.5s; AA=2.25s

crackle_form.pov
noAA=4.3s; AA=8.7s

3.6.1c (always 1 thread, of course):
crackle1.pov
noAA=3s; AA=5s

crackle_form.pov
noAA=13s; AA=27s

So in these cases it would seem the AA difference alone is typically an 
approximate doubling (or halving without AA) of rendering times, while 2 
threads is an obvious speed-up.
And 3.7 shows an improvement over 3.6 even when limited to 1 thread.

On a side note, I couldn't animate crackle_form.pov in 3.6 due to a 
freeze-up that required its "process" being shutdown. However, the 
unanimated renders have different appearances, such as a truncated cone part 
in the 3.6 image where only a small disc shows in 3.7 (amid other *pieces* 
of the crackle-made object), which I have no explanation for.

Bob H.

Post a reply to this message