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.

> I suggest the scene not use much more than 30 megs or so of memory.

That seems to be a good value. What's important is to be sure
it won't hold in the cache.

-- 
Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
 Mes propos n'engagent que moi et en aucun cas mes employeurs

Post a reply to this message

Ron Parker wrote:
> 

> >And it should be long enough to parse & render (I stick to my 2 hours on
> > a 1.4GHz Athlon (*))
> 
> But that would prevent people with real-world processors from participating
> at all. I hate to think how long it would take this P200 to run the
> benchmark, for example, but even a Duron 650 would have a tough time of it,
> and that's a current processor.  I'm sure I'm not the only one who doesn't
> expect to break the gigahertz barrier for at least another year or two.
> 

May I add that my current processor is a P200 underclocked for stability
at 180 with a lot of memory. If it took 2 Hours for a 1.4GHz, I would
expect my computer to take about two days. I do not see any problem about that.

If I were to just have a look at the image, whose size for the benchmark
should be bigger than 1600x1200, I could render it at 400x300, which would
be about 16 times faster (if only rendering was concerned), putting me
back in nearly realtime rendering (less than 3 hours).

We cannot have a reasonnable time for slow processor and enough 
provision for precision for fast futur processor and clustered things.

P.S. : I do not expect to upgrade before one full year, either.

Post a reply to this message

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.

The vast majority of POV-Ray users are also Windows users. Windows
notoriously uses quite a bit of the system memory resources. Good
or bad this is a fact that must be considered.

-- 
Ken Tyler

Post a reply to this message

Ken wrote:
> 
> Adrien Beau wrote:
> >
> > 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.
> 
> The vast majority of POV-Ray users are also Windows users. Windows
> notoriously uses quite a bit of the system memory resources. Good
> or bad this is a fact that must be considered.

I know that of course. There was some underground rant in my
answer. :-)

SDRAM is cheap nowadays, so owners of quite-recent computers
(less than two years old?) should be able to upgrade without
bothering for the money. In Paris, 128 MB RAM is around the
same price as an audio CD. I think the "standard" amount of
RAM "should" be 256 MB.

And anyway, I think 30 MB memory-usage is a good value.

-- 
Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
 Mes propos n'engagent que moi et en aucun cas mes employeurs

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3b810636@news.povray.org...
>   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.

Personally, I like that part.

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

Two hours for a benchmark seems a little excessive for me (especially on a
1.4gHz Athlon, which will make my 850mHz Duron seem like a slug...), but it
would make the benchmark last longer.  The problem with that, though, is
that in future years POV-Ray may well acquire new features / optimizations
which would mean we would need new test scenes.  We might have to rewrite
the test scenes before we even get to the 10 minute stage...

> : Really, faked entries are of no concern for commonly available systems:
> : When a lot of P2/400 MHz gives a render time of x, the x/30 entry is
> : obviously faked.
>
>   Of course, but I suppose that many people have the temptation to take
away
> a small but unnoticeable amount from the real rendering times (eg. if the
> real rendering time was 35 minutes, they could just report 31 minutes and
> no-one will notice). Unfortunately many people are like this; even if they
> don't get anything from that (not even their name anywhere), they still
tend
> to "exaggerate" a bit to look better.

I had never even thought of faking an entry.  It's a sad, sad world...
Seriously, if that's a problem, then write a small utility program that will
call POV with the appropriate options, grab the output and FTP / email the
results somewhere they can be accepted.  Unless the user wants to hack the
utility, no problem (I don't see why anyone would hack this, as it isn't
very interesting for people outside of this group, but then, I'm not most
people...)

...Chambers

Post a reply to this message

news:3B8111FD.BA95FF6D@atosorigin.com...
> *: remember, it's 2 hours for a huge size of at least 1600x1200 with AA.
> *, also: when a dual-athlon with 2GHz each will be available
>   (dual athlon is already, 2GHz probably in a few months/years), hoping
>   a port of povray 3.5+ (4.0 ??) will be multiprocessor compatible
>  (using the full power, with thread and so), the LONG 2Hr would be reduced
>  to only 40 minutes,
> and on a server with quad-mobo would only take 20 minutes...
> Try using a beowolf cluster of 64 of unexpensive 1GHz (by that time),
> and the theorical rendering drop to less than 3 minutes !
> If you do the computation with a shorter scene, you will found yourself
> with a precision problem sooner than you would have expected.

How many people do you know who have a Beowulf cluster at home?!?!?
I honestly know only one person who has a (home) computer in the gHz
range... and it's precisely 1 gHz.
Even though multiprocessor systems have been around for years, I still don't
know anyone who has one.

...Chambers

Post a reply to this message

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

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