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

> For example I designed this scene to take exactly 30 sec. to parse
> on my system.

9.0 here... What's in your computer?

--
Homepage: http://www.faricy.net/~davidf/
___     ______________________________
 | \     |_       <dav### [at] faricynet>
 |_/avid |ontaine      <ICQ 55354965>

Post a reply to this message

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

David Fontaine wrote:
> 
> > For example I designed this scene to take exactly 30 sec. to parse
> > on my system.
> 
> 9.0 here... What's in your computer?

  The question right now is not how fast you can render it. We can
start a "who's computer renders the code faster" thread later once
we establish the validity of the test. Until then your parse time
vs. my parse time is meaningless.

-- 
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

You need to know the specs of each computer to gauge the parsing algorithm
(I'll just go ahead and call it that anyway), don't you?

Bob

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3869C7CF.F62B7EF6@pacbell.net...
>
>   The question right now is not how fast you can render it. We can
> start a "who's computer renders the code faster" thread later once
> we establish the validity of the test. Until then your parse time
> vs. my parse time is meaningless.
>

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: which is inconsequential.

  What does this mean?

-- 
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

If you're asking what the word is, it's meaning as the AOL online dictionary
has it is:

in*con*se*quen*tial (adjective)

First appeared 1621

 1 a : ILLOGICAL

   b : IRRELEVANT

 2 : of no significance : UNIMPORTANT

 -- in*con*se*quen*ti*al*i*ty (noun)

 -- in*con*se*quen*tial*ly (adverb)

If not asking the definition, then I guess Ken will have to reply to any
other meaning.

Bob

"Nieminen Juha" <war### [at] punarastascstutfi> wrote in message
news:3869e319@news.povray.org...
> Ken <tyl### [at] pacbellnet> wrote:
> : which is inconsequential.
>
>   What does this mean?
>

Post a reply to this message

And POV-Ray for Windows v3.1g.  Don't know how I could have left that most
vital part out.

Bob

"omniVERSE" <inv### [at] aolcom> 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

Ron Parker wrote:
> 
> 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 

Sorry for cutting most of the message but this was the only thing I
think perhaps I disagree on. Most of the time rendering may take more
time than parsing but not in all cases. At the moment I'm rendering a
series of images where the parse time exceeds the render time. This, of
course is not very smart 8) In extreme cases it's better to do the heavy
calculations in an external program which will need only a fraction of
the time. Unfortunately this doesn't always work. I have noticed that
with the increasing power of my system I've concocted increasingly
complicated scenes which, even on a faster system, on average take
longer to render but even more so to parse (the more memory, the more
objects, the more parsing).

Just my two eurocents...

Remco

Post a reply to this message

In article <386a0a77@news.povray.org>, "omniVERSE" <inv### [at] aolcom> 
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.

My educated guess is that it is a compiler issue.

To get back to the original topic:
If you want to benchmark the parsing algorithm without benchmarking the 
disk, storing the scene file on a RAM disk should help.

--
Henri Sivonen
hen### [at] clinetfi
http://www.clinet.fi/~henris/

Post a reply to this message

I've rendered out to a ramdrive before.  There wasn't a difference, in
overall time anyway.

Bob

"Henri Sivonen" <hen### [at] clinetfi> wrote in message
news:henris-8B0D14.19312729121999@news.povray.org...
> In article <386a0a77@news.povray.org>, "omniVERSE" <inv### [at] aolcom>
> 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.
>
> My educated guess is that it is a compiler issue.
>
> To get back to the original topic:
> If you want to benchmark the parsing algorithm without benchmarking the
> disk, storing the scene file on a RAM disk should help.
>
> --
> Henri Sivonen
> hen### [at] clinetfi
> http://www.clinet.fi/~henris/

Post a reply to this message

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

In article <386A0DF0.A9F73E70@gci.net>, "mr.art" <mr.### [at] gcinet> 
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] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <386a0a77@news.povray.org>, "omniVERSE" <inv### [at] aolcom> 
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] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <386a0e59@news.povray.org>, "omniVERSE" <inv### [at] aolcom> 
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] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

>   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] faricynet>
 |_/avid |ontaine      <ICQ 55354965>

Post a reply to this message

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 ?
>
> 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

> 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

Ron Parker <par### [at] fwicom> wrote...
> 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.

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

> 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] faricynet>
 |_/avid |ontaine      <ICQ 55354965>

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 ?

    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

As you can probably guess, it was good for the first month only, now I'm
settled in once again.  Got it early October and gave up the old clunker to
the folks.  Just didn't want to rave about it much since afterall it is a
middle of the road machine anyway.
Got a stubborn render (or parse) though? Go ahead and let me know, see if
this thing can do it.

Bob

"Mike" <pov### [at] aolcom> wrote in message news:386AD3DC.E77A8282@aol.com...
>
> 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. :)
>

Post a reply to this message

Just read through this thread.
Interesting discussion to what I thought
was an interesting and inventive proposition.

I did run the scene with fairly typical
results and then ran it on my old 'puter.

I would now hereby like to make a public
apology to Ken Tyler for ever scoffing
or questioning his notion that Povray
could only be properly used on a
128MBram system.)

Peter Warren

Post a reply to this message

Peter Warren wrote:
> 
> Just read through this thread.
> Interesting discussion to what I thought
> was an interesting and inventive proposition.
> 
> I did run the scene with fairly typical
> results and then ran it on my old 'puter.
> 
> I would now hereby like to make a public
> apology to Ken Tyler for ever scoffing
> or questioning his notion that Povray
> could only be properly used on a
> 128MBram system.)
> 
> Peter Warren

Well I never really said you can't use a machine equiped with less memory
but is sure seems like it is becoming more difficult to do so. I would be
very happy to have a machine equipped with about 512 megs of memory and
would consider it my dream machine.

-- 
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

Ken wrote:
> 
> Well I never really said you can't use a machine equiped with less memory
> but is sure seems like it is becoming more difficult to do so. I would be
> very happy to have a machine equipped with about 512 megs of memory and
> would consider it my dream machine.
> 

Well why not 1024 megs? What would you like to do with it?
I have, as you might know, access to a machine with one GB RAM. It
doesn't change the world too much. I found the 48 megs of my PC at home
in 90% of the cases sufficient. Sometimes it makes me even more creative
when I develop something that can be rendered on my PC.

Marc

-- 
Marc Schimmler

Post a reply to this message

"Marc Schimmler" <sch### [at] icauni-stuttgartde> wrote in message
news:38734EFA.2E4DB1E3@ica.uni-stuttgart.de...
> Ken wrote:
> >
> > Well I never really said you can't use a machine equiped with less
memory
> > but is sure seems like it is becoming more difficult to do so. I would
be
> > very happy to have a machine equipped with about 512 megs of memory and
> > would consider it my dream machine.
> >
>
> Well why not 1024 megs? What would you like to do with it?
> I have, as you might know, access to a machine with one GB RAM. It
> doesn't change the world too much. I found the 48 megs of my PC at home
> in 90% of the cases sufficient. Sometimes it makes me even more creative
> when I develop something that can be rendered on my PC.
>
> Marc
>
> --
> Marc Schimmler

Right, and I never need anymore than 128MBytes for nearly ever file I ever
rendered with the exception of one or two.  That's just overkill to have
more than 256MB for me anyway.  Although obviously you could get pretty
limited with super massive (well, I'd call them super massive) scenes
calling upon millions of objects for certain uses (loops, meshes, etc.) with
only that much memory regardless of the disk space available to thrash
around in.
Some people are just going to use a large amount.  But I notice that 32MB
would do fine for most of my renders.

Bob

Post a reply to this message

Ken wrote in message <38734B98.1D083C3F@pacbell.net>...
>Well I never really said you can't use a machine equiped with less >memory
Sorry, Ken. I did not intend to misrepresent what you said.


It struck me a interesting what Matt said about trends in
pov scenes. There has been an iso patch for years but I
only used it for a few specific thing. Now I don't think
twice about using MegaPov.

I wonder what will be next.

Peter Warren
war### [at] hotmailcom

Post a reply to this message

Marc Schimmler wrote:


> Well why not 1024 megs? What would you like to do with it?
> I have, as you might know, access to a machine with one GB RAM. It
> doesn't change the world too much. I found the 48 megs of my PC at home
> in 90% of the cases sufficient. Sometimes it makes me even more creative
> when I develop something that can be rendered on my PC.

    In the best of all possible Windows on the world, as long as there is
enough RAM to avoid disk swaps, more is superfluous. Of course this includes
any other tasks that are running.

Post a reply to this message