Francois Dispot <woz### [at] club-internetfr> wrote:
: Warp's 2 hours suggestion

  It wasn't my suggestion.

  I think 2 hours is too much.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

On 20 Aug 2001 14:48:33 -0400, Warp wrote:
>Steve <ste### [at] zeroppsuklinuxnet> wrote:
>: There will be people on this group who have only one machine and 
>: have only 32M RAM and no opportunity to do upgrades such as OS or 
>: memory. 
>
>  When speaking about Windows, if you want more memory, you'll have to
>_downgrade_ to an older version, not upgrade to a newer. :P

By upgrade I didn't mean to a later version of Windows, nuff said. 

--
Cheers
Steve              email mailto:ste### [at] zeroppsuklinuxnet

%HAV-A-NICEDAY Error not enough coffee  0 pps. 

web http://www.zeropps.uklinux.net/

or  http://start.at/zero-pps

 12:15am  up 38 days,  2:19,  3 users,  load average: 1.04, 1.10, 1.14

Post a reply to this message

Steve <ste### [at] zeroppsuklinuxnet> wrote:
: nuff said. 

  By the way, what does this mean? I have seen it many times but I have
no idea...

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Greetings everyone (yes, I have been lurking out here for a bit... good
to be back after a long absense); Topic of conversation finally drew me
out of my shell for a brief de-lurk.

Ben has an idea here that I'd like to expand only with a twist:
namely, iteration.

Thing is, instead of parsing and rendering a scene (or several scenes) for
a benchmark, I think a couple of the problems mentioned in this thread might
be solved by having built-in timed iteration loops. Yes, I know, none of us
wants to see a bloat of POV itself in the official release, but perhaps an
unofficial version with the iteration patches built in could be distributed
for those who wanted to benchmark POV on their own system. Picture it
like this:

First, patch looks for a standard .pov file "benchmark.pov" (If it doesn't
exist,the testing patch could autogenerate it to ensure you're using the
right scene). Next, the processor repeatedly parses that file (which would be
chosen to contain things that really give the parsing routines a workout)
for a fixed period of time (relatively short, but enough to get a
statisticly valid reading), starting over each time the file is completed
(if it is!) so that even mega powerful machines will have something to do
for the full parse test. Benchmark the parsing capabilities of the machine
based on how many lines were parsed in the testing period.

Then choose a standard set of POV-Ray's internal functions to test, say,
>intersection testing of...
   a sphere,
   a julia fractal,
   a modestly complex isosurface,
   sequentially arranged transparent and/or reflective objects
>sampling of media,
>calculation of a few complex texture patterns
>(and whatever other features you felt it a good idea to include in a
benchmark.

Each of these functions would be called not in actual scene, but *as if*
you were calling them for a scene, in a timed loop, with the number of
calls completed within the predetermined timeframe being recorded as a
benchmark for that function. This way instead of using a factor such as
pixels per second, or the total amount of time for a given test scene, you
would measure how fast the test platform processes various commonly accessed
functions which contribute to the rendering of a scene. Among other things,
this would allow patch writers to plug their newer, presumably more
streamlined versions of existing functions into the iterative testing code
and see if in fact their revised source code (or choice of compiler) truly
made a difference to each given aspect of raytracing.

Presumably any characteristic of POV you wanted to benchmark could have
an iterative quantifier test designed and included in the patch, and since
the time factor for which the test is run would not vary regardless of the
system you run it on, you'd be measuring actual performance directly rather
than trying to infer performance from how long a particular scene took to
parse/trace.


Charles
----
The Silver Tome ::  http://www.silvertome.com
0x06: I am NOT a RESOURCE. I am a free man!!
0x02: Aaaahahahahahahaha...
--
"Ben Chambers" <bdc### [at] hotmailcom> wrote in message
news:3b813537@news.povray.org...
> Great conversation, all interesting thoughts, but here's another idea:
> How about an iterative/recursive benchmark?  Write a small external utility
> to call POV with custom scenes.  If POV returns too fast (say, under 5
> minutes) then it creates a slightly more complex scene and tries it again.
> It could even spit out different types of scenes (one where a number of
> spheres are randomly distributed in a space, or a reflective-sphere floating
> over a checkered plane with an area light that keeps getting more and more
> lights in it, or one that gets more and more levels of textures, or inside a
> reflective box and keep bumping up the max_recursion level).  For really
> slow processors, it would stop reasonably soon and say "OK, that's the limit
> of your processor", or, for really fast processors, it might have to keep
> bumping things up.  The benchmark, then, would not be render time but scene
> complexity.
> Any thoughts?
>
> ...Chambers
>
>

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3B80FDBA.D4B09876@gmx.de...
Porting Povray 3.5 to
> all platforms 3.1 currently runs on will take quite some time if it's
> possible at all (since a C++ compiler is needed)
>

    Is this true ? The fact that no-ones picked it up implies it is, I
guess, but I thought POV wasn't going C++ until 4.0...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

Warp wrote:
> 
> Steve <ste### [at] zeroppsuklinuxnet> wrote:
> : nuff said.
> 
>   By the way, what does this mean? I have seen it many times but I have
> no idea...

nuff said <-> enough said (on this subject).

-- 
Ken Tyler

Post a reply to this message

Warp wrote:
> 
> Steve <ste### [at] zeroppsuklinuxnet> wrote:
> : nuff said.
> 
>   By the way, what does this mean? I have seen it many times but I have
> no idea...
> 

I always thought of it as meaning "enough said" but I could be wrong.

Brendan

Post a reply to this message

Warp wrote in message <3b810636@news.povray.org>...

>: That's way too short.
>: It should take at least two hours on the 1.4GHz Athlon with enough
memory.
>
>  I think two hours is a bit overkill. Granted, 10 minutes may be too
short,
>but I think 2 hours is too much. I don't think people want to wait for
hours
>for this.
>  Or perhaps if 4 pov-files are used, the total time could be about 2
hours,
>which would mean a half-hour per file.


I'll repeat my earlier suggestion for a benchmark that will work equally
well on all systems: A benchmark image that spends almost all the time
actually rendering.  Fast systems should render at high resolutions, while
slow systems should render it at low resolutions.  The render time should
then be normalized to calculate how long that machine would have taken to
render the scene at some incredibly huge resolution (say, 40,000 x 30,000).

Examples:
A PII-400 renders at 640x480 in 652 seconds.  Since the area rendered is
1/3096.25 of the benchmark area, the time is multiplied by 3096.25 to get a
benchmark of 2,546,875, the estimated time to render the scene at
40000x30000.

A PIII-800 renders at 1024x768 in 750 seconds.  Since the area rendered is
1/1525.88 of the benchmark area, the time is multiplied by 1525.88 to get a
benchmark of 1,144,409.

A Beowulf cluster renders at 4000x3000 in 817 seconds.  Since the area is
1/100 of the benchmark area, the time is multiplied by 100 to get a
benchmark of 81,700.

--
Mark

Post a reply to this message

"Charles" <cfu### [at] enternet> wrote in message
news:3b819ecd@news.povray.org...
> <snip>

Well, it's interesting, but one of the things about rendering a full scene
is that you see the operations in action, ie, pseudo-random order thrashes
any looping speedups.  With modern processors, though (esp. those with big
caches) I don't know if this is really an issue.  Anyone else know?  Also, I
think it would be better just to write a separate utility which calls POV,
for space's sake.

Of course, there're probably as many ideas about how to do this as there are
people reading this thread... if not more... :)

...Chambers

Post a reply to this message

Scott Hill wrote:
> 
>     Is this true ? The fact that no-ones picked it up implies it is, I
> guess, but I thought POV wasn't going C++ until 4.0...
> 

I think it will be mainly plain C, but some parts require a C++ compiler.
IIRC Thorsten mentioned this quite some time ago.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message