In article <qqmiu2l5zsb.fsf_-_@goldach.fmi.uni-konstanz.de> , Thomas 
Willhalm <tho### [at] willhalmde>  wrote:

> I'm not too common with the way POV-Ray handles its memory.

OK :-)

> "Thorsten Froehlich" <tho### [at] trfde> writes:
>>
>> Whenever I profiled, I found that POV-Ray spends a lot of time doing memory
>> allocations...
>
> Couldn't it be useful to have two methods for allocation memory?
> 1) the POV_MALLOC used so far
> 2) a new method of memory that can only be freed on exit of the program.

Well, that would work for the command line versions, but it would create
various problems for the Windows and Macintosh GUI versions.

> With method 2), POV-Ray can allocate large parts of memory instead of little
> chunks. The size of the "little chunks" doesn't matter anymore and therefore
> needn't be stored. This decreases memory consumption and its handling
> by the OS.

The Mac version is currently doing this. You can get a memory allocation
down to about 100 cycles (plus a new allocation by calling the system every
- in case of the current Mac method - 16th call, on average) this way, but
there are easily a ten million or more allocations even for simple renders.
That makes billion cycles, or even on fast processors about 2 seconds just
for the cached allocations, plus about a 100000 cycles for the system memory
allocation functions (Mac OS). A simple example can be pyramid2.pov (a
sample scene that comes with POV-Ray 3.1). Rendering its default recursion
level (six) results in 23437 objects. Rendering those with 640 * 480 and
anti-aliasing (Method 1, Threshold 0.300, Depth 5, Jitter 0.00) ends up in
about five million memory allocations. Changing the whole thing to a glass
spheres


> The "large parts" could be handled by a linked list. Only for the
> last part -- the current one -- a pointer to the last byte (word) that is
> used is necessary.

You don't want to walk through lists, it is easier and more efficient to use
a bitmap (not the image term, the computer science term), a simple array of
bits which mark if memory in a particular location is used or not. You can
than use a few "bit tricks" and find an empty cell.  in order to not have to
mess around with different cell sizes you just divide cells into groups of
sizes, i.e. if a block of memory with 47 bytes is allocated, you allocate 47
* 32 bytes and manage those yourself. The next time an allocation for 47
bytes will be much faster (and POV-Ray uses a lot of blocks of the same
sizes). If you limit yourself to "caching" only the lower range of
allocations, i.e. 1 to 4096 bytes you can manage the whole "cache" of
allocated memory easily.

> However, I don't know whether:
> a) it's really faster

It is, but eliminated memory allocations in s"strategic" places all together
would speed things up even more. However, to do so quite a few modifications
in the source code of POV-Ray would be needed while changing the allocation
functions is simpler because they are external.

> b) the scenario for 2) occurs often enough in POV-Ray to justify the effort
> of implementing this.

It does, and doing it is not very difficult or a lot of work - the current
implementation on the PowerMac version of POV-Ray has just a few hundred
lines of code (however, due to a single inline assembler instruction used to
find a zero bit in a word (32 bits) it is not fully portable with the same
speed right now - but that is a very, very long story).


  Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message