 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And POV-Ray for Windows v3.1g. Don't know how I could have left that most
vital part out.
Bob
"omniVERSE" <inv### [at] aol com> wrote in message
news:3869a854@news.povray.org...
> Parse time of 8.0 sec. and render time of 3.0 sec. for a total of 11.0
> seconds.
> Pentium III 500MHz, 32KB L1 Cache, 512KB L2 Cache, 256MB 100MHz SDRAM,
> 13.4GB ATA66 7200RPM HardDisk.
> Win98SE at 68% Resources.
>
> Bob
>
> "David Fontaine" <dav### [at] faricynet> wrote in message
> news:386### [at] faricynet...
> > > For example I designed this scene to take exactly 30 sec. to parse
> > > on my system.
> >
> > 9.0 here... What's in your computer?
> >
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, I was asking for both the meaning of the word and what Ken meant with
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38698759.90BDCD6B@pacbell.net>, lin### [at] povrayorg
wrote:
> Benchmark testing generaly relies on the amount of time it takes
> to render a given scene. If one were to design a scene that was
> parsing intensive rather than render intensive how well would it
> evaluate a systems performance ?
>
> For example I designed this scene to take exactly 30 sec. to parse
> on my system. There is a camera added simply to ensure that it was
> not pointed at any object and there are no lights added so that I
> rendered a black screen only. Render time at 640x480 with aa = 0.3
> was only 8 sec. which is inconsequential. A pigment was added to
> the object to ensure that no CPU cycles were spent on sending no
> pigment warnings messages to the message window for each object
> created by the scene code.
>
> camera {location < 0, 0, -3 >look_at z*-6}
>
> #declare A = 0;
> #while (A<29500)
> sphere{<0,0,A>,1 pigment{rgb 1}}
> #declare A=A+1;
> #end
With the official 3.1g.r2, cache set to maximum:
Time For Parse: 0 hours 0 minutes 13.0 seconds (13 seconds)
Time For Trace: 0 hours 0 minutes 8.0 seconds (8 seconds)
Total Time: 0 hours 0 minutes 21.0 seconds (21 seconds)
With MacMegaPOV:
Time For Parse: 0 hours 0 minutes 14.0 seconds (14 seconds)
Time For Trace: 0 hours 0 minutes 1.0 seconds (1 seconds)
Total Time: 0 hours 0 minutes 15.0 seconds (15 seconds)
My computer is a Power Macintosh G3 266 "beige" desktop, with 96MB RAM,
booting from an external SCSI 9.1GB LaCie hard drive. The OS I ran these
tests under is Mac OS 8.6(I haven't gotten Mac OS 9 yet, and have been
too busy to do anything with LinuxPPC).
I would suggest a scene file that does some more complex calculations
instead of just creating a bunch of objects.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wow, hey, large difference in the render time for those two. I didn't think
there would be any significant change. Must be a Mac thing.
Just tried it myself and got a 9 sec parse with 3 sec again for render in
MegaPOV for Windows (although the =render= time has switched between 2 to 4
seconds on successive trials).
Bob
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-375B5B.07144329121999@news.povray.org...
> In article <38698759.90BDCD6B@pacbell.net>, lin### [at] povrayorg
> wrote:
>
> > Benchmark testing generaly relies on the amount of time it takes
> > to render a given scene. If one were to design a scene that was
> > parsing intensive rather than render intensive how well would it
> > evaluate a systems performance ?
> >
> > For example I designed this scene to take exactly 30 sec. to parse
> > on my system. There is a camera added simply to ensure that it was
> > not pointed at any object and there are no lights added so that I
> > rendered a black screen only. Render time at 640x480 with aa = 0.3
> > was only 8 sec. which is inconsequential. A pigment was added to
> > the object to ensure that no CPU cycles were spent on sending no
> > pigment warnings messages to the message window for each object
> > created by the scene code.
> >
> > camera {location < 0, 0, -3 >look_at z*-6}
> >
> > #declare A = 0;
> > #while (A<29500)
> > sphere{<0,0,A>,1 pigment{rgb 1}}
> > #declare A=A+1;
> > #end
>
> With the official 3.1g.r2, cache set to maximum:
> Time For Parse: 0 hours 0 minutes 13.0 seconds (13 seconds)
> Time For Trace: 0 hours 0 minutes 8.0 seconds (8 seconds)
> Total Time: 0 hours 0 minutes 21.0 seconds (21 seconds)
>
> With MacMegaPOV:
> Time For Parse: 0 hours 0 minutes 14.0 seconds (14 seconds)
> Time For Trace: 0 hours 0 minutes 1.0 seconds (1 seconds)
> Total Time: 0 hours 0 minutes 15.0 seconds (15 seconds)
>
> My computer is a Power Macintosh G3 266 "beige" desktop, with 96MB RAM,
> booting from an external SCSI 9.1GB LaCie hard drive. The OS I ran these
> tests under is Mac OS 8.6(I haven't gotten Mac OS 9 yet, and have been
> too busy to do anything with LinuxPPC).
>
> I would suggest a scene file that does some more complex calculations
> instead of just creating a bunch of objects.
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
omniVERSE wrote:
>
> Wow, hey, large difference in the render time for those two. I didn't think
> there would be any significant change. Must be a Mac thing.
> Just tried it myself and got a 9 sec parse with 3 sec again for render in
> MegaPOV for Windows (although the =render= time has switched between 2 to 4
> seconds on successive trials).
>
> Bob
You guy's are still missing the point here. I give up.
--
Wishing you Seasons Greetings and A Happy New Millennium !
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I always thought that the render was the most system intensive
part of the process.
Ken wrote:
>
> Benchmark testing generaly relies on the amount of time it takes
> to render a given scene. If one were to design a scene that was
> parsing intensive rather than render intensive how well would it
> evaluate a systems performance ?
>
> For example I designed this scene to take exactly 30 sec. to parse
> on my system. There is a camera added simply to ensure that it was
> not pointed at any object and there are no lights added so that I
> rendered a black screen only. Render time at 640x480 with aa = 0.3
> was only 8 sec. which is inconsequential. A pigment was added to
> the object to ensure that no CPU cycles were spent on sending no
> pigment warnings messages to the message window for each object
> created by the scene code.
>
> camera {location < 0, 0, -3 >look_at z*-6}
>
> #declare A = 0;
> #while (A<29500)
> sphere{<0,0,A>,1 pigment{rgb 1}}
> #declare A=A+1;
> #end
>
> --
> Wishing you Seasons Greetings and A Happy New Millennium !
> Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Back to the root of this thread.
The render time is obviously a video aspect to a machine, whereas the
parse time is going to be the real guts of it, ie. the CPU and associated
bus (and memory usage).
Ken is just saying his test script is an example of such a thing, unlike a
render intensive benchmarking. That should be the focus of this
conversation I guess, right Ken?
I would suggest leaving off the render part entirely for that matter, at
least by using the -d switch or Display=Off. How about the file
riting? -f or Output_to_File=Off.
I think Niemenin is onto something about the more complex parsing,
although the question might be then could it be independant of platform
used? Say, not work a CPU in a set way for one particular machine and
another differently? Actually I suppose that's one point about benchmarks
anyway.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Benchmark testing generaly relies on the amount of time it takes
> to render a given scene. If one were to design a scene that was
> parsing intensive rather than render intensive how well would it
> evaluate a systems performance ?
Comment:
- Rendering relies heavily on floating point operations.
- Parsing often relies more heavily on integer operations.
- Parsing can often use a lot of memory, so it can test memory
performance.
- Not that you asked, but lots of includes, big external files, etc. can
test disk performance.
Much depends on the nature of the code being parsed. You could write
code that requires a lot of floating point, tests the branch prediction
in your CPU, overflows cache and has to hit main memory a lot, etc.
I would suggest that benchmarks that don't rely on much extraneous
parsing would be most useful for determining how quickly a system
renders scenes, although a suite of scenes (rather than a single
skyvase.pov) might be useful.
-Mark Gordon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 28 Dec 1999 20:00:25 -0800, Ken <tyl### [at] pacbellnet> wrote:
>Benchmark testing generaly relies on the amount of time it takes
>to render a given scene. If one were to design a scene that was
>parsing intensive rather than render intensive how well would it
>evaluate a systems performance ?
Well, you're evaluating a part of the process that typically takes a
lot less time and doesn't tax the same parts of the architecture that
a render does. In particular, parsing is more concerned with file I/O
and memory allocation performance than with floating point
performance, so you're likely to see huge differences from filesystem
to filesystem and from OS to OS, even on the same computer.
Your example is probably more dependent on memory allocation than
anything else, so it might be a good measure of how fast your computer
can allocate memory. Whether that's a good gauge of performance is up
to you, but I'd say no.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Benchmark testing generaly relies on the amount of time it takes
> to render a given scene. If one were to design a scene that was
> parsing intensive rather than render intensive how well would it
> evaluate a systems performance ?
>
> For example I designed this scene to take exactly 30 sec. to parse
> on my system. There is a camera added simply to ensure that it was
> not pointed at any object and there are no lights added so that I
> rendered a black screen only. Render time at 640x480 with aa = 0.3
> was only 8 sec. which is inconsequential. A pigment was added to
> the object to ensure that no CPU cycles were spent on sending no
> pigment warnings messages to the message window for each object
> created by the scene code.
>
Parsing has more than one aspects to it. I'm no tech-expert so I can't
say much about it really but you might at least consider the actual
parsing (reading the scene), calculating (influenced by the type of
calculations - perhaps this is sytem-specific), creating objects and
memory management.
Perhaps you should have more then one benchmark file to test against all
of these (and more?) things.
??
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
