![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nieminen Juha
Subject: Poly is slower in megapov than in the official pov?
Date: 14 Feb 2000 07:24:03
Message: <38a7f3e3@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] student matnat uio no> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nathan Kopp
Subject: Re: Poly is slower in megapov than in the official pov?
Date: 14 Feb 2000 15:28:26
Message: <38a8656a@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nieminen Juha <war### [at] sarakerttunen cs tut fi> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: Poly is slower in megapov than in the official pov?
Date: 14 Feb 2000 16:34:36
Message: <38a874ec@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38a8656a@news.povray.org> , "Nathan Kopp" <Nat### [at] Kopp com>
wrote:
>
> Nieminen Juha <war### [at] sarakerttunen cs tut fi> 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] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nathan Kopp
Subject: Re: Poly is slower in megapov than in the official pov?
Date: 14 Feb 2000 18:07:24
Message: <38a88aac@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nathan Kopp
Subject: Re: Poly is slower in megapov than in the official pov?
Date: 14 Feb 2000 23:07:40
Message: <38a8d10c@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Rich <spa### [at] mindspring com> 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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nieminen Juha
Subject: Re: Poly is slower in megapov than in the official pov?
Date: 15 Feb 2000 04:01:52
Message: <38a91600@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nieminen Juha
Subject: Re: Poly is slower in megapov than in the official pov?
Date: 15 Feb 2000 05:02:49
Message: <38a92449@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38a91600@news.povray.org>, Nieminen Juha
<war### [at] sarakerttunen cs tut fi> 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] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: Poly is slower in megapov than in the official pov?
Date: 15 Feb 2000 09:57:08
Message: <38a96944@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38a91600@news.povray.org> , Nieminen Juha
<war### [at] sarakerttunen cs tut fi> 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] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |