Am 14.08.2016 um 09:35 schrieb Le_Forgeron:
> Le 13/08/2016 à 23:24, clipka a écrit :
>> Also, although it would theoretically be possible to replace the data
>> structure with a variable-sized one, any attempts at doing so have so
>> far resulted in severely degraded performance.
> 
> To avoid reallocation at each new element, you can reserve() some containers like
vector<>.
> Until the reserved number of element is reached, no more reallocation.
> But there is no signaling of the reservation being full, so after that you're back
to the reallocation.

The main drawback of vector<> is that there is /any/ allocation at all.
Or, more precisely, that a new instance of vector<> always does at least
one initial allocation.

The lists in question are used as temporary objects in recursive
function calls, and need to be created and discarded multiple times per
ray traced.

POV-Ray's homebrew FixedSimpleVector<> overcomes this problem by using a
static array instead of dynamically allocating memory, allowing it to
reside entirely on the stack.

> The less light-hearted programmers might even replace the default allocator for
something totally different.
> But gaining over the traditional malloc is hard, very hard.

Simply using a vector with a custom allocator isn't going to nail it,
that's for sure.

I have two main variants in mind that I plan on trying someday:

(A) Using a custom vector<>-ish type with a hybrid approach, using a
fixed static array plus dynamically allocated extra storage. This should
provide reasonably good performance for most scenes, while still
allowing pathological scenes to render, albeit at reduced performance.

(B) Allocating the entire vector<> dynamically (as opposed to just
letting vector<> allocate its data space dynamically), but not
discarding it after use, and instead keeping it around in a pool,
without trimming back its capacity. Next time such a vector would be
required, it would not be created anew but fetched from the pool, ready
for use without having to allocate memory for the data. This would still
result in poor performance for the first few rays, but should allow for
high performance throughout the bulk of the render even for pathological
scenes.

Post a reply to this message