|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
George Pantazopoulos wrote:
> I agree. Just because a patch does not appreciably speed up benchmark.pov
> does not mean that the patch isn't worthwhile. Why is benchmark.pov
> arbitrarily declared to be the ideal or typical POV-Ray scene, anyway?
> With so many possibilities of doing things in POV-Ray, is there even such
> a thing as "the typical scene" ?
Benchmark.pov was not "arbitrarily declared" a typical scene. It was carefully
designed to test a wide variety of feature sets present in the program and to
pose as a reasonable challenge to modern computing architectures. There is no
way a single scene is going to create a high level performance test for every
feature the program offers and even if you could it would take forever to
render. Instead we decided to craft a scene with a balanced set of features
that could reasonably be expected to test both the performance of the program
and the computers it is operated on while at the same time maintaining an
acceptable rending time. To date the developers have used it extensively for
fine tuning the performance of the program both internally and at compile
time and if it does nothing else it has performed beyond expectations for
accomplishing that.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 15 Jan 2004 10:42:09
Message: <4006b4d1@news.povray.org>
|
|
|
| |
| |
|
|
I fully agree with Ken.
benchmark.pov has been designed to mearure the rendering speed of typical
scenes in average.
However, I agree with George as well: If a feature does not slow down
benchmark.pov but considerably speeds up some feature which is rather
often used, in my opinion it's worth adding.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 15 Jan 2004 12:06:56
Message: <4006c8b0$1@news.povray.org>
|
|
|
| |
| |
|
|
In article <4006229C.572F22AE@pacbell.net> , Ken <tyl### [at] pacbellnet>
wrote:
> Benchmark.pov was not "arbitrarily declared" a typical scene. It was carefully
> designed to test a wide variety of feature sets present in the program and to
> pose as a reasonable challenge to modern computing architectures. There is no
> way a single scene is going to create a high level performance test for every
> feature the program offers and even if you could it would take forever to
> render. Instead we decided to craft a scene with a balanced set of features
> that could reasonably be expected to test both the performance of the program
> and the computers it is operated on while at the same time maintaining an
> acceptable rending time. To date the developers have used it extensively for
> fine tuning the performance of the program both internally and at compile
> time and if it does nothing else it has performed beyond expectations for
> accomplishing that.
While all you say is correct and remains valid, it has to be admitted that
benchmark.pov has one little bias as it does give a rather heavy weight to
the noise function due to the clouds. Another thing is that while it is a
realistic benchmark for comparing POV-Ray performance of roughly similar
systems (same architecture) when using them to do "real" work with POV-Ray,
it is not suitable to compare the performance of any particular
processor/system with a specific other one to determine which one is
"faster".
The reason is that such a comparison is not optimal with the default
benchmark.pov is that automatic bounding is turned on, which makes the major
task while rendering searching the bounding volumes. This to a major part
depends on memory access. It is really a lot of searching, but not so much
computing at all...
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
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 15 Jan 2004 12:32:06
Message: <kdvid1-8m.ln1@triton.imagico.de>
|
|
|
| |
| |
|
|
Andreas Kaiser wrote:
>>
>>The benchmark scene uses a reasonable amount of CSG, a comparison with
>
>
> I don't think so.
> Both of my private builds take about 38min for benchmark.pov (PIV
> 2.8GHz, 1GB RAM, options are -w384 -h384 +a0.3 +v -d -f -x).
>
> Setting use_photons = use_area_light = show_clouds = show_objects to
> false ==> about 114sec both.
> Additionally remove the Sockets ==> about 79sec both.
> So as a rough estimate the intersection objects only take about 2% of
> the total time.
Which is exactly the case for an average 'real' scene (real meaning not
a technical test scene but a true final scene for a real image). I
guess if you do a statistical analysis of some of the better POV-Ray
generated IRTC submissions you will find this confirmed. This is not
the case for scenes that make heavy use of isosurfaces and other objects
with expensive intersection tests.
I agree with Warp though that a weak performance in rendering
benchmark.pov is not at all a reason not to integrate this improvement.
The patch you posted in p.b.p. will make it quite difficult though
since you did not clearly mark your changes.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> While all you say is correct and remains valid, it has to be admitted that
> benchmark.pov has one little bias as it does give a rather heavy weight to
> the noise function due to the clouds.
Heavy use of the noise function is quite common for a typical POV-Ray
scene, even without media, due to procedural textures and geometry. In
a typical isosurface landscape scene it is even more excessive than in
benchmark.pov.
> The reason is that such a comparison is not optimal with the default
> benchmark.pov is that automatic bounding is turned on, which makes the major
> task while rendering searching the bounding volumes. This to a major part
> depends on memory access. It is really a lot of searching, but not so much
> computing at all...
Surely the use for comparing processors is limited by this but for
comparing the performance of whole computers concerning POV-Ray use this
is exactly what's needed - a typical POV-Ray render will spend much time
with memory access (in addition to bounding slabs just think of large
meshes, photon maps, radiosity, image maps).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4006b4d1@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> However, I agree with George as well: If a feature does not slow down
> benchmark.pov but considerably speeds up some feature which is rather
> often used, in my opinion it's worth adding.
I agree as well. The benefit will be moderate for most scenes, but many
scenes will render considerably faster. I'd say this is definitely a
worthwhile optimization.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
>[...]
>
>I agree with Warp though that a weak performance in rendering
>benchmark.pov is not at all a reason not to integrate this improvement.
> The patch you posted in p.b.p. will make it quite difficult though
>since you did not clearly mark your changes.
What's the preferred way to submit/mark changes?
For the posted csg.cpp:
function All_CSG_Union_Intersections,
lines 148 - 167, 183 - 185
function All_CSG_Intersection_Intersections completely,
function All_CSG_Merge_Intersections,
lines 436 - 438
BTW evaluation of 'tstPoint' at lines 277 and 278 is loop invariant
and should be moved just before the for-loop.
Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 16 Jan 2004 13:58:38 GMT, kai### [at] siemenscom (Andreas Kaiser)
wrote:
> What's the preferred way to submit/mark changes?
http://megapov.inetart.net/manual/internals.html#markup
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |