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

Nat### [at] Koppcom (Nathan Kopp) wrote in <38a8d10c@news.povray.org>:

>
>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.


    	I'll post it to text.scene-files after this one goes out.

Rich

Post a reply to this message