POV-Ray : Newsgroups : povray.beta-test : Major bug in SOR : Re: Major bug in SOR Server Time
31 Jul 2024 08:31:09 EDT (-0400)
  Re: Major bug in SOR  
From: Jérôme Grimbert
Date: 7 Sep 2001 07:02:11
Message: <3B98A937.C31A6867@atosorigin.com>
Warp wrote:
> 
> Anders K. <and### [at] f2scom> wrote:
> : P.S. Yeah, I know, it's too late for feature requests, but why do I have to
> : explicitly specify the number of elements in an array?
> 
>   I think it's because POV-Ray needs to allocate space for the array before
> it can put values into it.
> 
>   Of course it could be a dynamic array (std::vector), but I think the answer
> to this, as to many other things, is: POV-Ray 4.

Or the code will ended like the mesh parser in 3.1 : calling realloc everytime
that the array is too short... it is not very efficient, and moreover on 
computer with limited memory, a scene may failed to parse due to the system
being unable to provide a continuous memory zone: If the structure would need
66 unit, but the parser get to the end of 64 unit and try to double that amount,
you end up needing 128 unit + 64 possible units (if the system need to copy
them,
instead of extending): total need of 192 units of memory for a scene that would 
required only 66 units! 
Whereas, if you provide the count at the start, only 66 units are needed.

Powerful computer do not care, but small one might ! 
SOR was already available in DKBTrace, 
whereas mesh was introduced later. The difference reflects the evolution
of computers and programmers.
Small was beautiful, Nowadays every program must have fancy graphics and
waste as mush as possible memory and CPU.
Who need a smart programming when brute force provide the result in
bearable time (if you have the big CPU, of course!).


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.