![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/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) |
|
![](/i/fill.gif) |
Nat### [at] Kopp com (Nathan Kopp) wrote in <38a8d10c@news.povray.org>:
>
>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.
I'll post it to text.scene-files after this one goes out.
Rich
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |