I asked this before but no one explained it fully.
Mr. Froehlich mentioned something about Knuth,
numerous potential texture accesses during raytracing,
and implied that the answer should be patently obvious.

When POV loads a texture, it allocates a memory block
for each color channel and scanline of the image.
So a 256 pixel tall 24-bit RGB texture would take
256 x 3 = 768 memory blocks. I can't imagine that
this

The only two reasons I can imagine for using so many smaller
blocks is that

- The memory manager could page scanlines efficiently
  in and out of memory as they become popular and unpopular.
  But don't modern CPUs already do the paging automatically using some
small blocksize independant of higher-level
memory managers? I've never allocated textures
in such a fine-grained manner but have never
noticed a performance problem either.

Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

Sorry about that -- I somehow hit something
and the news reader posted the message in
the middle of composing it.

Take two:

The only two reasons I can imagine for using so many smaller
blocks is that:

- The memory manager could page scanlines efficiently
  in and out of memory as they become popular and unpopular.
  But don't modern CPUs already do the paging automatically using some
  small blocksize independant of higher-level memory managers? I've
  never allocated textures in such a fine-grained manner but have never
  noticed a performance problem either.

- Each scanline and its color data can start on a padded
  address boundary. But since the data is mostly bytes
  (8 bpp per channel or even 8 bpp per pixel), I don't
  see what difference that would make.


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

In article <3ee40ca7@news.povray.org> , "Ray Gardener" 
<ray### [at] daylongraphicscom> wrote:

> I asked this before but no one explained it fully.
> Mr. Froehlich mentioned something about Knuth,
> numerous potential texture accesses during raytracing,
> and implied that the answer should be patently obvious.

Per image you have, using common allocators (which use one native-size
pointer), plus one pointer for each color component, makes two pointers per
color component, and thus six pointers per line plus a pointer for the not
used transparency.  This is 28 bytes (32 bytes with transparency) per line,
regardless of the line width.  For a line that is only 256 pixels width, and
has no transparency, you get about 3.65% memory overhead, for a 1024 pixel
width image with transparency you get 0.78% memory overhead.

In the old days, such fine-grain access would indeed be faster as memory
access required no operations on the x-coordinate index (compared to
additions or even multiplications using more general access).  Today, this
does no longer matter.  But the space "wasted" by this kind of allocation
today no longer matters either.

There is a lot that can be optimised in POV-Ray, you should start where it
makes the most sense.  This requires profiling the code, and then to
optimise those spots.  Not to arbitrarily pick some segment of code and
optimise it, potentially introducing new bugs and gain, well, nothing at
all.

As Knuth really has shown over and over in his books, you first look for a
better algorithm, then you optimise that algorithm, not the other way
around.

    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

In article <3ee40ca7@news.povray.org>,
 "Ray Gardener" <ray### [at] daylongraphicscom> wrote:

> I asked this before but no one explained it fully.
> Mr. Froehlich mentioned something about Knuth,
> numerous potential texture accesses during raytracing,
> and implied that the answer should be patently obvious.

It is obvious. What you are doing is called "premature optimization".


> When POV loads a texture, it allocates a memory block
> for each color channel and scanline of the image.
> So a 256 pixel tall 24-bit RGB texture would take
> 256 x 3 = 768 memory blocks. I can't imagine that
> this

No, it does that when it loads an image. And so what? It's a convenient 
way to store images, though a little more work to allocate and free. 
There is probably no (non-trivial) scene in existence where you would 
get a useful speedup by implementing something else. Image allocation 
time is not an issue, looking at it is a waste of programmer time.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Okay, so we've established that there is no genuinely
useful reason why so many blocks are allocated.
The code is only the way it is because of legacy reasons.

For long-term maintenance, I just feel it would be
better to simplify the code than to leave it
complicated. Even if there's no performance increase,
it would make the code easier to understand, and
put less stress on the memory manager. As one
of POV-Ray's stated goals is to be an educational tool,
simplifying the code would help students, would it not?
What's the point of having unnecessary obsfucation
in an educational tool? Perhaps it might be a waste
of programmer time, but what about students' time?
And what if the existing code imparts the wrong lesson?

At the very least, put in a comment saying
"This code is overly complex. Given the choice,
we would have implemented it this way..."

--
Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

In article <3ee4dcf2@news.povray.org> , "Ray Gardener" 
<ray### [at] daylongraphicscom> wrote:

> Okay, so we've established that there is no genuinely
> useful reason why so many blocks are allocated.
> The code is only the way it is because of legacy reasons.
>
> For long-term maintenance, I just feel it would be
> better to simplify the code than to leave it
> complicated. Even if there's no performance increase,
> it would make the code easier to understand, and
> put less stress on the memory manager. As one
> of POV-Ray's stated goals is to be an educational tool,
> simplifying the code would help students, would it not?
> What's the point of having unnecessary obsfucation
> in an educational tool? Perhaps it might be a waste
> of programmer time, but what about students' time?
> And what if the existing code imparts the wrong lesson?
>
> At the very least, put in a comment saying
> "This code is overly complex. Given the choice,
> we would have implemented it this way..."

There is hardly a reason to improve code in 3.5 by rewriting it to make it
better when it will be thrown away in 4.0 anyway.  And many legacy pieces of
code will be thrown away.

In short: If it ain't broken, don't fix it.  Especially if you will replace
it completely in the next release anyway...

    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

Cool. Speaking of 4.0, are there any notes
describing what changes are planned and
how they will be approached?

--
Ray


"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3ee4deda@news.povray.org...
> In article <3ee4dcf2@news.povray.org> , "Ray Gardener"
> <ray### [at] daylongraphicscom> wrote:
>
> > Okay, so we've established that there is no genuinely
> > useful reason why so many blocks are allocated.
> > The code is only the way it is because of legacy reasons.
> >
> > For long-term maintenance, I just feel it would be
> > better to simplify the code than to leave it
> > complicated. Even if there's no performance increase,
> > it would make the code easier to understand, and
> > put less stress on the memory manager. As one
> > of POV-Ray's stated goals is to be an educational tool,
> > simplifying the code would help students, would it not?
> > What's the point of having unnecessary obsfucation
> > in an educational tool? Perhaps it might be a waste
> > of programmer time, but what about students' time?
> > And what if the existing code imparts the wrong lesson?
> >
> > At the very least, put in a comment saying
> > "This code is overly complex. Given the choice,
> > we would have implemented it this way..."
>
> There is hardly a reason to improve code in 3.5 by rewriting it to make it
> better when it will be thrown away in 4.0 anyway.  And many legacy pieces
of
> code will be thrown away.
>
> In short: If it ain't broken, don't fix it.  Especially if you will
replace
> it completely in the next release anyway...
>
>     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

Ray Gardener wrote:
> 
> Cool. Speaking of 4.0, are there any notes
> describing what changes are planned and
> how they will be approached?

The only real public information so far is the transistion from C to
C++. There was talk of a more open development model for 4.0 but I
know little of the details or when it is supposed to happen, if at
all. The POV-Team is still in the process of finalizing the release
of v3.51 so 4.0 is kind of on the back burner at the moment. Hopefully
once that is done they will give a better idea of their plans for 4.0
and what participation the public may play in that.

That said, you may want to take a look at -

   Subject: Proposal for 4.0 core control
      Date: Mon, 14 Oct 2002 17:47:23 +0200
      From: "Thorsten Froehlich" <tho### [at] trfde>
Newsgroups: povray.programming


and from Chris Cason in Sept. 2000,


 "Work on POV-Ray 4 has not yet begun.  However, there has been some
 discussion that we feel is of interest to the community.
 
 First, we have been discussing using a new license for 4.  Various
 open-source licenses are under consideration.  We might instead use an
 updated version of POVLEGAL.  No conclusions have been reached so far, but
 the topic is under discussion within the POV-Team.
 
 Second, we are also hoping to use a much more open development model for
 POV 4, with public read access to our source-revision tree.  System
 analysis, design, and implementation of POV 4 will be a very large task,
 and this is one way we hope to speed it up.  This open development model
 would also hopefully provide development releases (snapshots) more quickly
 to the power-user community, similar to what MegaPov offers now.
 
 Third, our most recent musings about POV-Ray 4 lean towards a major
 reworking of the POV Scene Description Language.  This means that POV 4
 may not be fully backwards compatible with old scenes.  If that is the
 case, we will plan to provide an official conversion utility that will
 convert old scenes into the new syntax, or provide some other means of
 importing old scenes. 

 Finally, the POV-Team is currently not going to be involved in any public
 discussion about POV 4.  We need to focus our efforts on POV 3.5.  Only
 after the release of POV 3.5 will work on version 4 begin.  The community
 can feel free to discuss this topic, but should not expect the POV-Team to
 read such discussions at this time."


How much of the above is still true is anyone's guess...

-- 
Ken Tyler

Post a reply to this message