 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Q: Is POV-Ray for DOS faster than POV-Ray for windows?
A: To my surprise the answer is: No.
It has been a known fact, that POV-Ray for Windows has been always slower
than POV-Ray for DOS.
This seem to be no longer true, at least with the MSVC compilation of
POV-Ray 3.1e for Windows.
I made a comprehensive test about this.
The machine: Pentium II 350MHz with 64 Megabytes of RAM.
The programs: All the tested programs are the 3.1e version of POV-Ray.
I tested with three compilations: The official MSVC compilation of
POV-Ray for Windows, the official Watcom compilation of POV-Ray for DOS
and my own DJGPP compilation of POV-Ray for DOS (with optimization flags
-O3 -mpentiumpro -funroll_loops).
The Windows version was run at the maximum priority without any other
programs running. The DOS versions were run from a raw DOS but with only
himem and smartdrv (except for the memory hog test in which I freed the
2 Megs occupied by smartdrv). For some strange reason I was unable to
make the cwsdpmi (the dos extender required by djgpp) to swap when it run
out of memory so there's no results for the memory hog test for the djgpp
compile. The DOS versions were also run with display turned off (the
Windows version was run with it turned on).
All tests were rendered at 640x480 pixels with antialiasing 0.1.
There was one big problem with the memory hog test with the DOS POV-Ray:
After rendering, the program spent about 20 minutes (!) just freeing the
swap file. The Windows version spent only a couple of minutes freeing the
memory.
So, the results:
Test1: 3 spheres
WinPov: 7 sec DosPovWat: 3 sec DosPovGcc: 4 sec
Test2: 10000 spheres
WinPov: 1 min 4 sec DosPovWat: 59 sec DosPovGcc: 1 min 2 sec
Test3: 4 planes
WinPov: 34 seconds DosPovWat: 30 sec DosPovGcc: 29 sec
Test4: 180 planes
WinPov: 4 min 50 sec DosPovWat: 4 min 51 sec DosPovGcc: 5 min 30 sec
Test5: 1 lathe
WinPov: 25 seconds DosPovWat: 27 sec DosPovGcc: 28 sec
Test6: 400 lathes
WinPov: 13 min 37 sec DosPovWat: 15 min 24 sec DosPovGcc: 16 min 22 sec
Test7: 218 objects (boxes, cylinders, torus, etc. using CSG, textures,
reflection...)
WinPov: 45 sec DosPovWat: 42 sec DosPovGcc: 46 sec
Test8.1: 7301 objects (of diverse type in CSG), 100 fading light sources and
2 area lights (memory hog, had to swap)
WinPov: 24 min 58 sec DosPovWat: 41 min 6 sec
Test8.2: Same scene but with only 50 light sources
WinPov: 22 min 31 sec DosPovWat: 24 min 16 sec
Test9: 7 glass objects (using caustics), 1 plane, focal blur
WinPov: 29 min 17 sec DosPovWat: 30 min 46 sec DosPovGcc: 31 min 33 sec
Test10: A 512x512 heightfield with a 512x512 image map
WinPov: 1 min 58 sec DosPovWat: 2 min 11 sec DosPovGcc: 2 min 1 sec
Test11: 81 copies of that heightfield
WinPov: 5 min 55 sec DosPovWat: 6 min 42 sec DosPovGcc: 6 min 19 sec
Test12: A little mesh, a plane and scattering media
WinPov: 5 min 57 sec DosPovWat: 5 min 33 sec DosPovGcc: 6 min 58 sec
Test13: Some simple objects, an area light and radiosity
WinPov: 17 min 35 sec DosPovWat: 28 min 24 sec DosPovGcc: 21 min 14 sec
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Q: Is POV-Ray for DOS faster than POV-Ray for windows?
>
> A: To my surprise the answer is: No.
>
Those are some interesting results. They seem to mirror the results
I recieved when testing between the differently compiled windows versions
and 3.1 releases. It certainly supports using the msvc build of windows
if speed is your need. Where is the results for the Mac ?
Some day instead of saying to someone going on an important mission
"God speed with you " we will be able to say instead "Pov speed with you"
Wouldn't that be nice ?
Can I presume that this will be added to the VFAQ ?
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm a little astounded. Contradictory, I know, "little", "astounded".
Starting to read that I first thought, okay WinPOV is doing better
maybe. By the time I finished looking at it the variances, for the
better mostly are way different than my expectations.
Is the DOS memory stuff just outdated or something?
And that lathe, well, I figured it had to be a Windows cohort all along
anyhow, if you know what I mean.
Nice testing Nieminen.
What's a Mac? j/k! Don't test on one, if I found out it cuts rendering
50% I'd have to get me one.
Ken wrote:
>
> Nieminen Mika wrote:
> >
> > Q: Is POV-Ray for DOS faster than POV-Ray for windows?
> >
> > A: To my surprise the answer is: No.
> >
>
> Those are some interesting results. They seem to mirror the results
> I recieved when testing between the differently compiled windows versions
> and 3.1 releases. It certainly supports using the msvc build of windows
> if speed is your need. Where is the results for the Mac ?
>
> Some day instead of saying to someone going on an important mission
> "God speed with you " we will be able to say instead "Pov speed with you"
> Wouldn't that be nice ?
>
> Can I presume that this will be added to the VFAQ ?
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aol com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> I'm a little astounded. Contradictory, I know, "little", "astounded".
> Starting to read that I first thought, okay WinPOV is doing better
> maybe. By the time I finished looking at it the variances, for the
> better mostly are way different than my expectations.
> Is the DOS memory stuff just outdated or something?
> And that lathe, well, I figured it had to be a Windows cohort all along
> anyhow, if you know what I mean.
> Nice testing Nieminen.
> What's a Mac? j/k! Don't test on one, if I found out it cuts rendering
> 50% I'd have to get me one.
>
> Ken wrote:
The lathe differences were noted between Pov-Ray version changes
and using the different compilers for the Windows program. This recent
test is a straight line test with the same version of Pov-Ray used
throughout the test range. I was seeing the most difference between
Pov v3.1r1 watcom and Pov v3.1d msvc6. There were a few revisions in
between and completely different programming software usedto compile it.
My results will stand unchallenged by this latest test.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 23 Apr 1999, Nieminen Mika wrote:
<snip>
> There was one big problem with the memory hog test with the DOS POV-Ray:
>After rendering, the program spent about 20 minutes (!) just freeing the
>swap file. The Windows version spent only a couple of minutes freeing the
>memory.
This has an easy explination.
in DOS, the program removes the whole swap file frrom the drive, it's a rather
cumbersome procedure to first empty it, and then remove it. While windows
leaves it all "as is" and only overwrites it as necessary afterwards.
If you think about it for a while I think you'll see why the speed difference
appears in this case.
//Spider
--KRN sucks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> What's a Mac? j/k! Don't test on one, if I found out it cuts rendering
> 50% I'd have to get me one.
Don't worry, testing between my AMD K6 and a Mac G3 (both 233 Mhz)
shows that the Mac takes almost twice the time to complete the same
rendering. The "unofficial povray" for macintosh uses another compiler
and is faster, but still don't get close to the K6...
Cheers,
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37204af9.0@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
wrote:
> Q: Is POV-Ray for DOS faster than POV-Ray for windows?
>
> A: To my surprise the answer is: No.
>
> It has been a known fact, that POV-Ray for Windows has been always slower
> than POV-Ray for DOS.
> This seem to be no longer true, at least with the MSVC compilation of
> POV-Ray 3.1e for Windows.
>
> I made a comprehensive test about this.
> The machine: Pentium II 350MHz with 64 Megabytes of RAM.
> The programs: All the tested programs are the 3.1e version of POV-Ray.
> I tested with three compilations: The official MSVC compilation of
> POV-Ray for Windows, the official Watcom compilation of POV-Ray for DOS
> and my own DJGPP compilation of POV-Ray for DOS (with optimization flags
> -O3 -mpentiumpro -funroll_loops).
> The Windows version was run at the maximum priority without any other
> programs running. The DOS versions were run from a raw DOS but with only
> himem and smartdrv (except for the memory hog test in which I freed the
> 2 Megs occupied by smartdrv). For some strange reason I was unable to
> make the cwsdpmi (the dos extender required by djgpp) to swap when it run
> out of memory so there's no results for the memory hog test for the djgpp
> compile. The DOS versions were also run with display turned off (the
> Windows version was run with it turned on).
> All tests were rendered at 640x480 pixels with antialiasing 0.1.
> There was one big problem with the memory hog test with the DOS POV-Ray:
> After rendering, the program spent about 20 minutes (!) just freeing the
> swap file. The Windows version spent only a couple of minutes freeing the
> memory.
>
> So, the results:
>
> Test1: 3 spheres
> WinPov: 7 sec DosPovWat: 3 sec DosPovGcc: 4 sec
>
> Test2: 10000 spheres
> WinPov: 1 min 4 sec DosPovWat: 59 sec DosPovGcc: 1 min 2 sec
>
> Test3: 4 planes
> WinPov: 34 seconds DosPovWat: 30 sec DosPovGcc: 29 sec
>
> Test4: 180 planes
> WinPov: 4 min 50 sec DosPovWat: 4 min 51 sec DosPovGcc: 5 min 30 sec
>
> Test5: 1 lathe
> WinPov: 25 seconds DosPovWat: 27 sec DosPovGcc: 28 sec
>
> Test6: 400 lathes
> WinPov: 13 min 37 sec DosPovWat: 15 min 24 sec DosPovGcc: 16 min 22 sec
>
> Test7: 218 objects (boxes, cylinders, torus, etc. using CSG, textures,
> reflection...)
> WinPov: 45 sec DosPovWat: 42 sec DosPovGcc: 46 sec
>
> Test8.1: 7301 objects (of diverse type in CSG), 100 fading light sources and
> 2 area lights (memory hog, had to swap)
> WinPov: 24 min 58 sec DosPovWat: 41 min 6 sec
>
> Test8.2: Same scene but with only 50 light sources
> WinPov: 22 min 31 sec DosPovWat: 24 min 16 sec
>
> Test9: 7 glass objects (using caustics), 1 plane, focal blur
> WinPov: 29 min 17 sec DosPovWat: 30 min 46 sec DosPovGcc: 31 min 33 sec
>
> Test10: A 512x512 heightfield with a 512x512 image map
> WinPov: 1 min 58 sec DosPovWat: 2 min 11 sec DosPovGcc: 2 min 1 sec
>
> Test11: 81 copies of that heightfield
> WinPov: 5 min 55 sec DosPovWat: 6 min 42 sec DosPovGcc: 6 min 19 sec
>
> Test12: A little mesh, a plane and scattering media
> WinPov: 5 min 57 sec DosPovWat: 5 min 33 sec DosPovGcc: 6 min 58 sec
>
> Test13: Some simple objects, an area light and radiosity
> WinPov: 17 min 35 sec DosPovWat: 28 min 24 sec DosPovGcc: 21 min 14 sec
Which scene files did you use exactly? Any intention to make them public
(and an INI file with all the settings, too)?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3720E5E5.F3BB1996@compuserve.com> , Fabien Mosen
<101### [at] compuservecom> wrote:
>> What's a Mac? j/k! Don't test on one, if I found out it cuts rendering
>> 50% I'd have to get me one.
>
> Don't worry, testing between my AMD K6 and a Mac G3 (both 233 Mhz)
> shows that the Mac takes almost twice the time to complete the same
> rendering.
3.1a was very slow, 3.1d is more than 30% faster...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37210ba5.0@news.povray.org> , "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:
> 3.1a was very slow, 3.1d is more than 30% faster...
Than the 3.1a _not_ than the Windows version!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> 3.1a was very slow, 3.1d is more than 30% faster...
>
> Thorsten
the test was done with 3.1d...
the good news is that the "unofficial Pov" is somewhat faster,
so that particular Mac user switched to it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.msdos Thorsten Froehlich <fro### [at] charliecnsiitedu> wrote:
: Which scene files did you use exactly? Any intention to make them public
: (and an INI file with all the settings, too)?
You can download them from http://iki.fi/warp/sptest.zip
--
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 <37231d2f.0@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
wrote:
> You can download them from http://iki.fi/warp/sptest.zip
Thank you!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37231d2f.0@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
wrote:
> You can download them from http://iki.fi/warp/sptest.zip
Hmm, the first few scenes render ok, but you forgot to include hf.tga.
I haven't rendered the long ones yet (will do so tonight).
Here are the results so far for my PowerMac G3/300, 64 MB, virtual memory on
(note that this is _not_ based on the official compile, but the same
compiler with slightly different settings):
Test 1:
Time For Trace: 0 hours 0 minutes 5.0 seconds (5 seconds)
Total Time: 0 hours 0 minutes 5.0 seconds (5 seconds)
Test 2:
Time For Parse: 0 hours 0 minutes 2.0 seconds (2 seconds)
Time For Trace: 0 hours 0 minutes 12.0 seconds (12 seconds)
Test3:
Time For Trace: 0 hours 0 minutes 9.0 seconds (9 seconds)
Total Time: 0 hours 0 minutes 9.0 seconds (9 seconds)
Test 4:
Time For Trace: 0 hours 3 minutes 46.0 seconds (226 seconds)
Total Time: 0 hours 3 minutes 46.0 seconds (226 seconds)
Test 5:
Time For Trace: 0 hours 0 minutes 13.0 seconds (13 seconds)
Total Time: 0 hours 0 minutes 13.0 seconds (13 seconds)
Test 6:
Time For Trace: 0 hours 2 minutes 30.0 seconds (150 seconds)
Total Time: 0 hours 2 minutes 30.0 seconds (150 seconds)
Test 7:
Time For Trace: 0 hours 0 minutes 7.0 seconds (7 seconds)
Total Time: 0 hours 0 minutes 7.0 seconds (7 seconds)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37234e00.0@news.povray.org> , "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:
> In article <37231d2f.0@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
> wrote:
>
>> You can download them from http://iki.fi/warp/sptest.zip
>
> Hmm, the first few scenes render ok, but you forgot to include hf.tga.
> I haven't rendered the long ones yet (will do so tonight).
> Here are the results so far for my PowerMac G3/300, 64 MB, virtual memory on
> (note that this is _not_ based on the official compile, but the same
> compiler with slightly different settings):
>
> Test 1:
> Time For Trace: 0 hours 0 minutes 5.0 seconds (5 seconds)
> Total Time: 0 hours 0 minutes 5.0 seconds (5 seconds)
>
> Test 2:
> Time For Parse: 0 hours 0 minutes 2.0 seconds (2 seconds)
> Time For Trace: 0 hours 0 minutes 12.0 seconds (12 seconds)
>
> Test3:
> Time For Trace: 0 hours 0 minutes 9.0 seconds (9 seconds)
> Total Time: 0 hours 0 minutes 9.0 seconds (9 seconds)
>
> Test 4:
> Time For Trace: 0 hours 3 minutes 46.0 seconds (226 seconds)
> Total Time: 0 hours 3 minutes 46.0 seconds (226 seconds)
>
> Test 5:
> Time For Trace: 0 hours 0 minutes 13.0 seconds (13 seconds)
> Total Time: 0 hours 0 minutes 13.0 seconds (13 seconds)
>
> Test 6:
> Time For Trace: 0 hours 2 minutes 30.0 seconds (150 seconds)
> Total Time: 0 hours 2 minutes 30.0 seconds (150 seconds)
>
> Test 7:
> Time For Trace: 0 hours 0 minutes 7.0 seconds (7 seconds)
> Total Time: 0 hours 0 minutes 7.0 seconds (7 seconds)
Please ignore these numbers, they do ***not*** represent results with the
same settings (for some reason AA wasn't on...). Sorry!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37235c9d.0@news.povray.org> , "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:
> In article <37234e00.0@news.povray.org> , "Thorsten Froehlich"
> <fro### [at] charliecnsiitedu> wrote:
>
> Please ignore these numbers, they do ***not*** represent results with the
> same settings (for some reason AA wasn't on...). Sorry!
And here are the corrected numbers:
Test 1:
Time For Trace: 0 hours 0 minutes 5.0 seconds (5 seconds)
Total Time: 0 hours 0 minutes 5.0 seconds (5 seconds)
Test 2:
Time For Parse: 0 hours 0 minutes 2.0 seconds (2 seconds)
Time For Trace: 0 hours 1 minutes 5.0 seconds (65 seconds)
Total Time: 0 hours 1 minutes 7.0 seconds (67 seconds)
Test 3:
Time For Trace: 0 hours 0 minutes 22.0 seconds (22 seconds)
Total Time: 0 hours 0 minutes 22.0 seconds (22 seconds)
Test 4:
Time For Trace: 0 hours 5 minutes 42.0 seconds (342 seconds)
Total Time: 0 hours 5 minutes 42.0 seconds (342 seconds)
Test 5:
Time For Trace: 0 hours 0 minutes 20.0 seconds (20 seconds)
Total Time: 0 hours 0 minutes 20.0 seconds (20 seconds)
Test 6:
Time For Trace: 0 hours 10 minutes 16.0 seconds (616 seconds)
Total Time: 0 hours 10 minutes 16.0 seconds (616 seconds)
Test 7:
Time For Trace: 0 hours 0 minutes 41.0 seconds (41 seconds)
Total Time: 0 hours 0 minutes 41.0 seconds (41 seconds)
One note on test 5 and 6: Mac compilers can optimise the lathe code much
better and are therefore much faster than PCs.
One major reason why (even when very few memory allocations occure) the Mac
version is slower is the way POV-Ray represents colors, vectors and almost
all basic types: arrays. The compilers do _not_ manage to use the 32
floating-point registers, instead they nearly always generate load/store
instructions so all the RISC benefits are gone :-(
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.general Thorsten Froehlich <fro### [at] charliecnsiitedu> wrote:
: Hmm, the first few scenes render ok, but you forgot to include hf.tga.
It was intentional (I wanted to keep the size of the file small). You can
use any 512x512 24 bit tga you want for the heightfield and another image
(with equal dimensions) for the image map.
--
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 <37248869.0@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
wrote:
> It was intentional (I wanted to keep the size of the file small). You can
> use any 512x512 24 bit tga you want for the heightfield and another image
> (with equal dimensions) for the image map.
OK, however, I am not sure if this won't change the results (but I haven't
looked into the heigh-field code so it may not).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3724b617.0@news.povray.org> , "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:
> In article <37248869.0@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
> wrote:
>
>> It was intentional (I wanted to keep the size of the file small). You can
>> use any 512x512 24 bit tga you want for the heightfield and another image
>> (with equal dimensions) for the image map.
>
> OK, however, I am not sure if this won't change the results (but I haven't
> looked into the heigh-field code so it may not).
Hmm, it seems to matter. For test 10 I got 49 seconds and for test 11 156
seconds. Can you please make the hf and texture available, too?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It should matter - if the HF image is different, the shape is different, and
in most cases the number of intersections with the shape is different, too.
The texture image should have little effect, though.
Margus
Thorsten Froehlich wrote in message <3724ba6e.0@news.povray.org>...
>>
>> OK, however, I am not sure if this won't change the results (but I
haven't
>> looked into the heigh-field code so it may not).
>
>Hmm, it seems to matter. For test 10 I got 49 seconds and for test 11 156
>seconds. Can you please make the hf and texture available, too?
>
>
> Thorsten
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have experienced that too. Tried the standard Skyvase-benchtest and
under Win98 it took 1m 15s, and under DOS 1m 13s. Now if I could only
become competent enough to get Linux running properly... ;)
Sven-Erik Andersen
sea### [at] mailcitycom
http://www.geocities.com/SiliconValley/Program/2549/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
