|
 |
One question : Is there any possibility to download this wonder somewhere ?
Cheers
> Chris Cason asked me to share these early test results with you.
>
> I have been doing some testing for Chris Cason to compare the
> differences in performance of Pov v3.1b compiled using watcom and
> the Pov v3.1d compiled using msvc6 a c++ compiler. Because there
> was such a performance increase seen in the msvc6 version he also
> sent me a copy of Pov v3.1d compiled with watcom. These are the
> test results I obtained using the three different versions and
> compilers used for the test.
>
> There are some surprises ahead for you and I believe you will
> be as surprised as I have been. In both compiler versions they
> have been optimised for a Pentium II system but it is evident
> that instructions used for the optimization also help in the
> earlier Pentium I class machines like I use.
>
> My system:
> Pentium - 200 mmx 512k cache 128 megs edo ram on a Win98 platform.
>
> Enjoy !
>
> ----------------------------------------------
> First report to Chris compares Pov v3.1d.msvc vs. Pov v3.1b.watcom
>
> Control for Tests:
>
> 1.) All global parameters were allowed to default except GUI and
> Render Priority were set to highest.
>
> 2.) All background applications were terminated.
>
> 3.) Each set of tests ran sequencialy for each compiled version
> and no other programs on the system were started in between
> versions runs.
>
> 4.) All data reported comes from Pov-Ray message window
>
> 5.) Where the system used the hard drive to swap out memory it
> has been noted as such even though the results indicate it
> made little difference in the comparison of the two compiles.
>
> Results of Tests Run
> --------------------
>
> -------------------
> Test1 - Sphere Test
> Purpose:
> Test difference between compiles against parsing time using scaleable
> quanities of simple to render but longer to parse objects. In this
> case the sphere objects was choosen as it renders quickly but the
> high numbers increase the parsing time.
>
> Test Objects:
> This test used a nested while loop to produce uniform numbers of 1 unit
> spheres with rgb 1 pigment, default finish, 1 light source and 1 camera.
> Render times will not be accurate as the majority of spheres are outside
> the angle of view of the camera. The important numbers are those showing
> the parsing time vs. numbers of objects generated.
>
> Comparison Results:
> parse t render t swap
> test #objects Peak Memory Min Sec Min Sec file
> pov 3.1 b 1 100 150,326 0 0 0 6 No
> pov 3.1 d 1 100 155.430 0 1 0 4 No
>
> pov 3.1 b 2 1000 823,778 0 2 0 6 No
> pov 3.1 d 2 1000 883,550 0 2 0 5 No
>
> pov 3.1 b 3 10000 7,737,986 0 10 0 10 No
> pov 3.1 d 3 10000 7,890,322 0 12 0 8 No
>
> pov 3.1 b 4 100000 77,600,314 2 15 0 17 No
> pov 3.1 d 4 100000 79,434,254 1 59 0 15 No
>
> ---------------------
> Test2 - hairball test
> Purpose:
> Test difference between compiles against file that contains a large number
> of objects generated by several nested loops, known to require both large
> amounts of memory, long parsing times, and long rendering times.
>
> Test Objects:
> A mesh of 12 triangles was created. These were used in a nested loop to
> create a patch of triangle objects, This patch was used inside another
> nested loop to create a hemispherical globe - looks like half a hairball.
> The first loop was incrememted from the first test with 25% of it's
> number of objects to 100% in the last test run.
>
> Comparison Results:
> parse t render t swap
> test #objects Peak Memory Min Sec Min Sec file
> pov 3.1 B 1 18631 14,139,656 0 14 3 6 No
> pov 3.1 D 1 18631 14,141,544 0 13 2 44 No
>
> pov 3.1 B 2 51751 38,559,004 0 34 7 17 No
> pov 3.1 D 2 51751 38,560,892 0 30 6 30 No
>
> pov 3.1 B 3 132481 98,081,212 1 39 16 45 Yes
> pov 3.1 D 3 132481 98,083,184 1 42 14 52 Yes
>
> pov 3.1 B 4 207001 153,024,808 8 48 29 10 Yes
> pov 3.1 D 4 207001 153,026,780 6 57 27 25 Yes
>
> Observation: Times were better for both parsing and rendering with
> less that a 1% sacrifice in the amount of memory needed.
>
> ----------------------------------------
> Test3: Lathe/surperellispoid Object Test
>
> Purpose: test difference between compiles against objects
> requiring higher order math funtions and textures that were both
> layered and reflective.
>
> This test used a 74 point qauadratic spline lathe with a 6 layer
> crackled texture and reflective finish. Also present were a brick
> floor created by placing scaled superellipsiods in place with a
> nested loop - objects were given single pigment but high values
> of reflecion 0.45. A gradient sky_sphere was used to add color to
> the scene so the reflections would have an impact on the render time.
> The slower_yet_more_accurate sturm keyword was used with the lathe object.
>
> Comparison Results:
> parse t render t swap
> test #objects Peak Memory Min Sec Min Sec file
> pov 3.1 B 1 43 171,303 1 37 8 No
> pov 3.1 D 1 43 177,027 1 4 8 No
>
> pov 3.1 B 2 43 171,303 1 37 7 No
> pov 3.1 D 2 43 177,027 1 4 8 No
>
> Note: Since there was such a large difference in the render times
> of v3.1b and v3.1d the test was repeated. A variance of only 1 second
> for four renders supports the results. Amazing !!!
>
> -----------------------------------
>
> Report to Chris #2
>
> A few more render comparisons on the lathe object. What a difference !
>
> 20 point lathe object
> 3.1d 3.1b
> cubic_spline 41 sec 9m 57s
>
> quadratic_spline
> w/sturm 38 sec 9m 6s
> wo/sturm 23 sec 1m 7s
>
> linear_spline 22 sec 46s
>
> bezier_spline 48 sec 3m 38s
>
> ---------------------------------------------
> Report to Chris #3
>
> This last adds the v3.1d watcom compile to the comparisons to see if
> the previous results were a compiler related speed up or a version
> related speed up. It appears it is more version related than compiler
> though the msvc6 version is fastest of the three so far.
>
> Ken
>
> Pov v3.1 d.msvc vs. Pov v3.1d.watcom vs. Pov v3.1b.watcom
>
> --------------------------------------------
> 20 point Lathe Using Different Spline Types:
>
> v3.1d-msvc v3.1d-watcom v3.1b.watcom
> quadratic
> w/sturm 38 s 47 s 9m 6 s
> wo/sturm 23 s 27 s 1m 7 s
>
> linear 22 s 25 s 46 s
> cubic 41 s 53 s 9m 57 s
> bezier 48 s 1m 1 s 3m 38 s
>
> -----------------------------------------
> Objects From Shapesq.inc Comparison Test.
>
> v3.1d.msvc.win32 v3.1d.watcom.win32 v3.1b.watcom.win32.r1
> wo/sturm w/sturm wo/sturm w/sturm wo/sturm w/sturm
> bicorn 22s 24s 24s 27s 25s 28s
> Crossed_Trough 25s 42s 29s 55s 31s 58s
> Cubic_Cylinder 30s 48s 36s 1m 1s 39s 1m 6s
> Cubic_Saddle_1 30s 46s 37s 57s 40s 1m 1s
> Devils_Curve 31s 46s 36s 57s 40s 1m 1s
> Helix_1 27s 57s 27s 1m 5s 29s 1m 11s
> glob_5 1m 34s 1m 37s 1m 59s 2m 4s 2m 7s 2m 9s
>
> total time 4m 31s 6m 0s 5m 13s 7m 43s 5m 51s 7m 9s
> ---------------- ---------------- -----------------
>
> --------------------------
> Traditional Sky_Vase Test:
> memory memory memory
> Sky_Vase.Pov 2m 16s 150,015 2m 7s 145,095 2m 19s 145,051
>
> ---------------------------------------------
> Lathe/Surperellispoid Object Comparison Test:
>
> parse t render t swap
> test #objects Peak Memory Min Sec Min Sec file
> pov 3.1 b.w 1 43 171,303 1 37 8 No
> pov 3.1 d.w 1 43 171,383 1 4 34 No
> pov 3.1 d.v 1 43 177,027 1 4 8 No
>
> Note: Notice large difference in speed between versions.
>
> ------------------------------
> Large Pov Generated Mesh Test:
> parse t render t swap
> test #objects Peak Memory Min Sec Min Sec file
> pov 3.1 b.w 1 18631 14,139,656 0 14 3 6 No
> pov 3.1 d.w 1 18631 14,139,736 0 13 3 1 No
> pov 3.1 d.v 1 18631 14,141,544 0 13 2 44 No
>
> pov 3.1 b.w 2 51751 38,559,004 0 34 7 17 No
> pov 3.1 d.w 2 51751 38,559,084 33 7 3 No
> pov 3.1 d.v 2 51751 38,560,892 0 30 6 30 No
>
> pov 3.1 b.w 3 132481 98,081,212 1 39 16 45 Yes
> pov 3.1 d.w 3 132481 98,081,292 1 37 16 6 Yes
> pov 3.1 d.v 3 132481 98,083,184 1 42 14 52 Yes
>
> ----------------------------------------------------------------
>
> As you can see from my tests you should expect to see some signifigant
> improvement in your render times with certain types of scenes. On other
> types there will be little gain noticed but with raytracing it's every
> little bit that counts.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
