On Mon, 20 Aug 2001 16:08:17 +0200, Adrien Beau wrote:
>Ken wrote:
>> 
>> There are still people running machines with much less
>> than 128 megs and even those people with 128 megs installed have
>> the OS using up much of those resources.
>
>Then they have a problem. They shouldn't use an OS that eats
>the vast majority of the installed RAM. Either they use an OS
>that eats less memory, or intall more memory.

That's not allways an option, I find that people tend to have as 
much hardware as they can afford.  I have one machine here with 
Win 95 which has 32 M RAM, and if I get more memory it's going in 
the main box, not in the Win 95 machine. 

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. 

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

  6:35pm  up 37 days, 20:39,  2 users,  load average: 1.02, 1.03, 1.00

Post a reply to this message

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

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

Here is my two bits:

I would prefer one scene file. That should be a scene that uses as many
of Pov's features as possible, perhaps with the exception of those
dependend of bitmaps, to avoid having to download large bitmap files
along with the benchmark scene file.

To get around the problem of a slow enough scene for state of the art
processors being too slow for older systems, I propose the following
system:

The benchmark should be expressed as the speed relative to a reference
system (like Andreas Tillner's ChessMark (see www.tabsnet.de)). On the
reference system (say a Athlon 1GHz, 64MB RAM, Windows, official PovRay
compile), the scene is rendered at several different resolutions (say
from 320x240 to 3200x2400). On fast system you choose a high resolution,
on slow systems a low resolution for running the benchmark. To avoid
timing inaccuracy, a minimum render time should be set. 

/Ib

Post a reply to this message

Heavily snipped from Ib Rasmussen's post:  (the following had stuff where there
are blank lines)

>I would prefer one scene file. That should be a scene that uses as many

>To get around the problem of a slow enough scene for state of the art

>compile), the scene is rendered at several different resolutions (say
>from 320x240 to 3200x2400). On fast system you choose a high resolution,
>on slow systems a low resolution for running the benchmark. To avoid

The problem with using a single file, and multiple resolutions to try to
compensate for different machines is that it only compensates for differences
in the rendering time.  If you've got a scene that takes several minutes for
the wonder-machine to parse, then my lowly P1-133 with 24Mb memory might take
?hours? (or some large  amount of time anyways) to parse it, even though I'm 
only doing the render at 320x240.

The same with memory issues.  128 Mb is becoming a fairly standard amount of
memory in a new machine.  So to really test how POV performs for large memory
accesses, you should use a reasonable chunk of that.  Which is going to drive
my machine into swapping, since memory is as much a function of number of
objects in the scene as it is of rendering resolution.

Ultimately, for accurate testing, what's probably needed is several catagories
of test files (parse time, memory usage, render time, etc) at several different
levels (from 486-66 to drool-worthy-super-machine).  

You could then run up the scale of increasingly-demanding tests until you got
a meaningfull time (say order 10 min), and post your results indicating both
what time, and which test.

Admittedly, this gets complicated, in several terms: creating various test
files, probably create a utility to automatically run them and post the results
(that or very good directions), finding a good way to display the results,
etc.

Jamie

Post a reply to this message

I think that in cases where the current benchmark is too slow you should
render it as an animation with 10 or 100 or even 1000 frames and then divide
the total render time with the number of frames rendered. All the frames
would be the same but that the whole point that makes this method work...
Memory wouldn't be very high, but who says the POV-Ray benchmark has to
measure memory speed anyway.

This solution would be by far the simplest and it would be fully comparable
to test that have already been performed.

...Just a different (and perhaps slightly boring) approach to the problem...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

> But that would prevent people with real-world processors from
participating
> at all.

I agree.

Jim

Post a reply to this message

Good idea!

Just my 2 cents concerning multiprocessing or clustered thingies: the
current problem (which has been the case for at least two years) is that
the fastest clusters are completely saturated by the amount of data to
move. I remember reading that being unable to even send blocks to part
of the nodes is quite common now.

The well known fact that the "usual" pvmpov has a 4s delay to wait for
stats when everything is over makes it clear that on such hardware
nobody will beat pvmegapov on skyvase, since the delay is 1s ;-)

I would suggest a reverse approach: ideally, I would like to get a 1%
accuracy on results from a *fast* cluster available when povray 3.5 is
out. This means an average timing of 100s on a 64 nodes cluster with
dual Athlon MP 1.6 GHz. Very roughly speaking, taking into account the
limited scalability of clusters, this means that Warp's 2 hours
suggestion would be perfect for this purpose. On the other hand this
means that the p200 box I'm currently using would take 2 days.
-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

There is a new (OK, not well known) POVRAY-Benchmark at
http://www.tabsnet.com/ waiting of your results. A overclocked Athlon
Thunderbird 1000@1620 MHz needs 00:05:21 to render the example chess2.pov
with the this parameter : povray -d -q9 +w800 +h600 +b1000 +r3 +a0.300 +v1
+ft . And there are some supercomputer at the list of Multi-CPU-Systems.
Every Benchmarkresult is very welcome.

Regards,
   Tilly,

Post a reply to this message

Good idea, and probably long overdue too.

I agree with Warp's original idea that there should be several different
types of scenes, including one all-rounder.  This would allow those who
favour a certain type of scene to make meaningful comparisons.  For
example, if someone likes scenes with lots of plants built from
enourmous meshes, then they may well be much more interested in seeing
the benchmarks for scenes with high memory usage, and high parsing times
(if e.g. their plants were procedurally created and placed).  And of
course the all-round scene is vital for an overall comparison.

Perhaps it is not so important to accomodate those with lower spec
computers.  I would assume that one of the main uses of a benchmarking
system is to compare the performance of higher-end systems, as the
results for these would be very helpful for anyone thinking of upgrading
(e.g. Athlon/P4 comparisons).  Of course, there is the case of those
deciding which OS to run on a lower spec machine that will be used for
rendering, but perhaps with enough results publicly available, they
could get their answer without having to do the test themselves.

As regards rendering time - it might be wise to keep it under 10 hours,
but not too far under so as to allow for future developments.  This
would be handy for leaving the computer on overnight whilst rendering
the scene.  Longer times would be difficult to trust, as people may well
have used the computer for other things during the render.  Slower
computers that had been playing MP3s at the same time would return
results that were not really worth anything.  Well, unless there was a
benchmark category for rendering whilst playing music :-)

Oh, I guess we should decide pretty soon, as someone's going to have to
produce the scenes in the first place, and it would make sense for them
to be in the 3.5 distribution.

Post a reply to this message

Warp wrote:

>
>
>   The idea behind this is that some computers are better in one of those than
> in another, and this kind of test gives a good idea where is that computer
> good at.
>   One single scene can't test all of those things, and even if it does
> (as in the 4th example), one can't see how well the computer performs in
> the individual tasks.
>

I agree with this*, an aggregate result could easily hide some interesting
comparisons, which brings me to my footnote:
* what is the actual purpose(s) of a benchmark scene?

Jim

Post a reply to this message