I noticed that the poly primitive renders slower in megapov (0.4) than
in the official povray (at least in this ultrasparc). I wrote about this
in p.b.i. Why is this so?
  Another thing I noticed was that the equivalent isosurface renders faster
than the poly (even when the poly is rendered in the official povray). Should
the poly primitive be optimized so that it's at least as fast as the
isosurface?

  Here is a copy of the original article I sent:


Simen Kvaal <sim### [at] studentmatnatuiono> wrote:
: Looks good, man! What was the render time for it? (Just comparing.)

  I made a modified version of my scene for the comparison:

//=========================================================================
#declare UseIso = no;

camera { location <8,20,-10>*.7 look_at x*.01 angle 35 }
light_source { <100,200,20> 1 }
background { rgb y }
#if(UseIso)
  #version unofficial MegaPOV 0.4;
  isosurface
  { function { 2*x*sqr(y)/(sqr(x)+sqr(y*y))-z }
    contained_by { box { <-4,-4,-1><4,4,1> } }
    open
#else
  poly
  { 5,
    <0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,-2,
    0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>
    sturm
    clipped_by { box { <-4,-4,-1><4,4,1> } } bounded_by { clipped_by }
#end
    pigment { rgb <1,.7,.3> } finish { specular .5 }
    rotate <0,90,-90>
  }
//=========================================================================

  Changing the first line will choose the type of surface (poly or iso).
Choosing "no" will make the scene renderable with the official povray.
The images generated look quite identical. The rendering times in this
UltraSparc5 using "-w512 -h385 +a0.1" were:

Poly (with povray 3.1g):
    Total Time:    0 hours  0 minutes  53.0 seconds (53 seconds)

Poly (with megapov 0.4):
    Total Time:    0 hours  0 minutes  57.0 seconds (57 seconds)

Iso (with megapov 0.4):
    Total Time:    0 hours  0 minutes  40.0 seconds (40 seconds)

  Surprisingly enough, the isosurface is faster than the poly.
  Oddly enough, the poly is slightly slower in megapov than in the official
pov.

  Question: Should the poly be optimized to be at least as fast as the
isosurface?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha <war### [at] sarakerttunencstutfi> wrote...
>   I noticed that the poly primitive renders slower in megapov (0.4) than
> in the official povray (at least in this ultrasparc). I wrote about this
> in p.b.i. Why is this so?

Probably because the official version is a Watcom compile and MegaPov is a
MSVC++ compile, and they each do slightly different optimizations.

I think the source code is the same between the two.

-Nathan

Post a reply to this message

In article <38a8656a@news.povray.org> , "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

>
> Nieminen Juha <war### [at] sarakerttunencstutfi> wrote...
>>   I noticed that the poly primitive renders slower in megapov (0.4) than
>> in the official povray (at least in this ultrasparc). I wrote about this
>> in p.b.i. Why is this so?
>
> Probably because the official version is a Watcom compile and MegaPov is a
> MSVC++ compile, and they each do slightly different optimizations.
>
> I think the source code is the same between the two.

Hmm, Nathan, if I am not completely misunderstanding Nieminen, this happens
on a Sun UltraSparc Station, not an Intel PC...


     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

Thorsten Froehlich <tho### [at] trfde> wrote...
> Hmm, Nathan, if I am not completely misunderstanding Nieminen, this
happens
> on a Sun UltraSparc Station, not an Intel PC...

Hmmm... you're right... I guess I should have paid attention when I read his
post.  ;-)

Anyway, the polysolv.c and poly.c in MegaPov are the same as the official
3.1g versions.

-Nathan

Post a reply to this message

Are you sure it's the polys you're noticing a slowdown on?  I have noticed 
that MegaPOV is slower than the official release in general, but I don't know 
where the slowing is occuring.  An example is a scene I have used for 
benchmarking versions of POV and PC upgrades, consisting of a simple sky-sphere 
and 18 spheres; 9 are glass, the other 9 are chrome.  No special code, just 
simple, basic POV primitives.  The render results are as follows:

    	POV 3.1g (official release)    	3min 54sec
    	POV 3.1g (MSVC++ complied)    	3min 37sec
    	MegaPOV 0.4    	    	    	    	5min  4sec

    	These renders were done on a new P3-600mhz PC with 128mb RAM and a 32mb 
video card.  I installed Windows98 SE on a freshly formatted HDD, then 
installed POV/POV MSVC/MegaPOV and ran the tests.  MegaPOV is slower than the 
official release, no doubt about it.  I can post my simple scene if anyone 
wants to see it.

Rich

Post a reply to this message

Rich <spa### [at] mindspringcom> wrote...
>     POV 3.1g (official release)    3min 54sec
>     POV 3.1g (MSVC++ complied)    3min 37sec
>     MegaPOV 0.4                5min  4sec

That is a considerable difference.  Please send me the scene and I'll see if
I can find ways to optimize MegaPov.  I think the problem here might have to
do with refraction and reflection (the dispersion patch and blurred
reflection patch), though I would not have expected that much of a
difference in speed.

-Nathan

Post a reply to this message

I have a theory. It may be one cause of the slowdown, or it may not.
  Anyways, when I was looking at the pov source code in order to see how to
implement my fractal patch, I noticed that there are several places where
there are huge switch-case-constructs (for example when selecting the
pattern type or when parsing a keyword).
  Now megapov has LOTS of additional patterns, keywords, etc. Thus, those
switch-constructs are likewise a lot bigger.

  I don't know how the compiler handles those switch constructs, but if the
item to be selected is an integer type, I can't think of anything but a
bunch of if...else if...else if... structures. This, of course, is rather
slow when there is a considerable amount of cases.

  I'm not completely sure about this either, but I think that if the item
to be selected is an enum type, the compiler is able to optimize it so that
it can construct a look-up table with jumping addresses, and thus it can
generate a code that just indexes this table with the item and jumps to
that address. This is a lot faster, as you can imagine.

  I noticed that most things are #defined as integer constant in the povray
source code. For example:

#define BOZO_PATTERN            13
#define MARBLE_PATTERN          14
#define WOOD_PATTERN            15
#define SPOTTED_PATTERN         16

and so on.

  Perhaps it could be worth trying with an enum type instead? This way:

enum Pattern_type
{ BOZO_PATTERN,
  MARBLE_PATTERN,
  WOOD_PATTERN,
  SPOTTED_PATTERN,
  ...
}

  Of course every type that uses these values have to be changed from "int"
to "Pattern_type", but it _might_ generate a bit faster code, so it may
be worth the effort.
  Of course it could be tested with a test program before making the job.
  Hmm... I have to test it myself (if I find the time to do it...).

  This also makes it easier to add new types (the numeration changes
automatically as needed), so if nothing else, it's worth because of that.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Well, I was wrong. There's no difference in speed if using #defined
integers or an enum type.
  I made a program that generates two programs, one with 5000 #defines and
another with an enum of 5000 items. Then the program loops through all
those 5000 values 100000 times (ie. 500000000 loops in total) with a
switch-structure inside (each branch adds a value to a variable).
  There's no remarkable difference in speed between the two.

  (I can post the source code of the program if anyone wants it...)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38a91600@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   I noticed that most things are #defined as integer constant in the 
>   povray source code. For example:
...
> and so on.
> 
>   Perhaps it could be worth trying with an enum type instead? This way:

MegaPOV already uses an enum, look in pattern.h:

enum PATTERN_IDS
{
  NO_PATTERN = 0,
  PLAIN_PATTERN,
  AVERAGE_PATTERN,
  BITMAP_PATTERN,
...


>   This also makes it easier to add new types (the numeration changes
> automatically as needed), so if nothing else, it's worth because of that.

It certainly does, having to renumber many of the entries just to add 
one thing was quite annoying...
I think any possible speed increase would be heavily compiler dependant, 
though.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38a91600@news.povray.org> , Nieminen Juha 
<war### [at] sarakerttunencstutfi>  wrote:

>   I don't know how the compiler handles those switch constructs, but if the
> item to be selected is an integer type, I can't think of anything but a
> bunch of if...else if...else if... structures. This, of course, is rather
> slow when there is a considerable amount of cases.

No, usually it is done by a jump table (if the case variables are close and
not distributed over the whole range of integers - a long story :-)  ).  You
can then have a constant time to perform the switch-case.  Just thing of it
as and array of function points (not exactly the same, but close enough to
get the idea):

switch(i)
{
    case 1:
        // .....
        break;
    case 2:
        // .....
        break;
    case 3:
        // .....
        break;
    default:
        // .....
        break;
}

int (*casefunc)()[3];

if(i < 0 || i > 2)
    // default
else
    // case casefunc[i]()



       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