Rudy Velthuis wrote:

> Have a look at the dramatic speed improvements achieved in POV-Ray 3.1d for
> some higher order objects (cubics, quartics, superelllipsoids, etc). I don't
> think they suddenly turned to assembler, but they must have redesigned some
> algorithms.
> 
> >* No problem is too large that a faster clock rate can't fix.
> 
> >dik

A word from Ken:

  Let's examine that speed improvement for just a moment. The items
in the scene were a quadratic spline using sturm, this had a 6 layer
semitransparent texture applied, and a hand full of superellipsoids.
  As I watched the scene render it was evident that the most time
consumed during the render operation was spent on the lathe object.
I would discount the superellipsoids from the speed improvement as
their addition to the render time was not much more than the other
versions.
  There is also the case where I simply used objects from shapesq.inc,
with and without sturm, that don't show near the increase in performance
you would expect as seen with the quadratic spline late object. While
there was improvement in general it wasn't on so high an order.
  There were also several bug fixes in this version and who is to say
what impact they may have had been having. I think the test data I
provided is good general indication of what can be expected as far as
increased performance from v3.1b and v3.1d. It only implies the reasons
the speed has been improved without disclosing why it is better.
  What were the contributing factors involved in this performance increase ?
I don't know, but the data should not have unsubstantiated value added
to it. What I presumed I was testing, and what the results indicate, may
be improperly assigned to the wrong attribute and should be taken into
consideration when examining the data.
  Obviously they have been reworking some of the code to make it ready
to become a full c++ compliant program (as mentioned in Chris Young's bug
fix report) and that may be what is adding to the performance. Without
direct knowledge of the changes and their implementation would be idle
speculation and not worthy of serious discussion.

My point is don't try to read too much into that data I provided because
it may be full of traps.

One more thing: Don't worry - Be happy.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message