![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
So, what you want to know is if there is a seperate parsing "engine" and
a rendering "engine"? And can they be seperately optimized for
benchmarking purposes so that the parsing "engine" is platform
independant?
Or am I just gibbering?
Colin ;)
Ken originally 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 ?
>
Ken then wrote:
>
> You guy's are still missing the point here. I give up.
>
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 <386A0DF0.A9F73E70@gci.net>, "mr.art" <mr.### [at] gci net>
wrote:
> I always thought that the render was the most system intensive
> part of the process.
It usually is, but sometimes it is the other way around. For example, if
your POV file includes particle simulations or tree/plant generation
macros, the parse time can easily exceed the render time.
And just as the rendering can be benchmarked, so can the parsing. Doing
tests on the parsing might reveal ways to speed it up or to write faster
parsing scenes.
--
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) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <386a0a77@news.povray.org>, "omniVERSE" <inv### [at] aol com>
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.
Well, there is a big difference in the chips. I have a G3, which is
*very* fast at integer calculations, but not very fast at floating
point. Parsing this scene probably uses mostly integer math.
Another thing is that the Mac version of POV-Ray has a memory cache
feature which can really speed things up, especially in allocating
memory(which is mainly what this scene is doing, allocating memory for
those spheres).
And last but definitely not least, the compilers used different. The Mac
version is compiled with CodeWarrior, I don't know about the Windows
version.
--
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) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <386a0e59@news.povray.org>, "omniVERSE" <inv### [at] aol com>
wrote:
> 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).
Nope, the video portions of the computer are not used in rendering.
Rendering mostly tests the floating point performance of the
microprocessor and the access speed of the RAM.
The only effect the video parts would have are in displaying the
rendered image on the screen, and that is probably almost unnoticeable.
And you can always turn the display off.
> 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.
That doesn't turn the render off, just the display of the rendered
image. The best way to minimize the render time interfering with the
parse time would be to set a very small image size(like 4*4 pixels).
--
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) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> The question right now is not how fast you can render it.
-?-
That was entirely the parse time.
--
Homepage: http://www.faricy.net/~davidf/
___ ______________________________
| \ |_ <dav### [at] faricy net>
|_/avid |ontaine <ICQ 55354965>
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) |
Ken <tyl### [at] pacbell net> 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.
[snip]
I guess what you're mostly measuring with a test such as the one you posted
is the speed of memory allocation and filling (there aren't any complicated
transformations or other CPU-intensive parsing tasks). This speed would be
affected by the physical speed of your RAM, the amount you have (and the
amount available under multi-tasking OS's), the drivers used to access it,
and probably the compiler used to make the POV-Ray executable.
All in all, benchmark tests of any kind can really only measure the speed of
tasks similar to what the test itself does, and even using POV-Ray there are
wildly different parsing tasks, eg. smoothing large heightfields or creating
subdivided bicubic patches, calling macros (particularly when they are
included from separate files), calculating bounding boxes and vista and
light buffers, etc.
Perhaps the best test of parsing and rendering is a scene which includes
many varied elements, giving something as close to a 'real-world' test as
possible?
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) |
> Pentium III 500MHz, 32KB L1 Cache, 512KB L2 Cache, 256MB 100MHz SDRAM,
> 13.4GB ATA66 7200RPM HardDisk.
> Win98SE at 68% Resources.
Damn Bob, when did you get that sweet machine!? If I'm ever pressed for
time on a render I'll know who to call. :)
-Mike
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) |
Ron Parker <par### [at] fwi com> wrote...
> On Tue, 28 Dec 1999 20:00:25 -0800, Ken <tyl### [at] pacbell net> 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.
Yes. For example, with #while loops and macros, POV uses the 'fseek()'
function to get to the appropriate place in the file and parses it.
Especially if you use many macros that are spread across many files, you'll
find that this will be a test of the quality of the disk caches (both
hardware and software caches).
> 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.
The speed of memory allocation and deallocation can depend on the compiler
used and the operating system. I once saw a paper that compared the speed
of various implementations of malloc() and free().
Also, as Chris Colefax pointed out, the exact nature of the POV script will
have an affect on the characteristics of the parse, which may make it
dependent on the speed of your floating-point math.
-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) |
> Pentium III 500MHz, 32KB L1 Cache, 512KB L2 Cache, 256MB 100MHz SDRAM,
> 13.4GB ATA66 7200RPM HardDisk.
mumble grumble
You just wait, I'll get that Athlon someday...
By the time my dad buys it it will be obsolete...
--
Homepage: http://www.faricy.net/~davidf/
___ ______________________________
| \ |_ <dav### [at] faricy net>
|_/avid |ontaine <ICQ 55354965>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Matt Giwer
Subject: Re: Parsing vs. Rendering Performance
Date: 30 Dec 1999 02:22:40
Message: <386B3260.2E38D48@ij.net>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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 ?
OK, let me ask you then, what is the point? With the conditions you set
up the issue appears trivial, the faster the clock the better.
Benchmarks were the original drivers in the PC business. As soon as one
became popular software was optimized to do well on the benchmark. That lead
to a suite of benchmarks with the intention making them such that everything
had to be optimized to be overall better.
But what does that mean to the user? It depends what you use it for.
Everyone writes to file but some do it more often than others. Folks playing
action games differ from those who place chess. What does a great video
benchmark mean to the chess players? or rendering folks for that matter?
If the trend is towards pov scenes that are parse intensive certainly
there is going to be a call for faster parsing. And for the IRTC animation
competition image size parsing time is a non-neglibable consideration.
Benchmark just a sphere compared to a superellipsoid of <2,2>. Same
shape but different rendering times.
Everything about the computer can affect the time required. Why should
not everything about a scene have an effect? And therefore, what is the
benchmark to test?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |