Ken wrote:
> 
> Warp wrote:
> >

> > : Then, you would have multiple metrics. IMNSHO, it's a bad thing, because
> > : everyone will wants soon it's own test scene.
> > : You should rather stick to a single scene, which should nevertheless
> > : be a complex-looking and lovely one.
> >
> >   I'm not sure if I understand what do you mean.
> 
> There should be only one scene file. You are making it much too
> complicated.

Exactly, Ken :-)

The scene file should produce a beautiful image
          (so as to astonish the new users),
And it should be long enough to parse & render (I stick to my 2 hours on 
 a 1.4GHz Athlon (*))
  (at least, it should start to teach patience** to the new users,
 hence, it must be a beautiful image which looks complicated)

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

** I must confess, I started with DKBtrace 2.12 a long time ago 
and it took more than one week to render ntreal on a poor CPU (without FPU).
(no harddisk either, all was on floppy !). It was a time when one had
better to thing the scene rather than trying multiple preview.
Mosaic preview was a great thing then!

Post a reply to this message

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

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Warp wrote:
> 
>   2. These scene files should take a reasonable amount of time in current
> computers. This amount should be chosen so that it will not be in the order
> of a couple of seconds in a few years. For example they could take about 10
> minutes each in an 1.2GHz Athlon.

Not enough, as others noted. I remember seeing entries like
several minutes for early Pentiums (that's the last time I
checked the bench pages) and several hours for 386.

I think nowadays it would be half an hour or more for around
1 GHz processors.

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

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