 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello:
I seem to recall some discussion somewhere comparing rendering times of
skyvase.pov as a sort of hardware benchmark (It DOES take 100% of my OS/CPU
resources, according to Win98 System Monitor.)
640x480 No AA
Using a 400 Celeron overclocked to 500, 83 MHz bus, I get skyvase times
around 48-50 sec. ...about 5 times faster than my 233MMX.
Here's the rub: using TWO CPUs on motherboard, o/c to same 500 (let's hear a
big Tool Time "GHz! Arr! Arr! Arr!" grunt), NT4.0 (only service pack 1 so
far) seeing both CPUs, times are no better- maybe even slightly slower.
Have not tried multiple instances.
Whuzz happnin? Where's the beef?
Thanks,
Matt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Swarm wrote:
>
> Hello:
>
> I seem to recall some discussion somewhere comparing rendering times of
> skyvase.pov as a sort of hardware benchmark (It DOES take 100% of my OS/CPU
> resources, according to Win98 System Monitor.)
>
> 640x480 No AA
>
> Using a 400 Celeron overclocked to 500, 83 MHz bus, I get skyvase times
> around 48-50 sec. ...about 5 times faster than my 233MMX.
>
> Here's the rub: using TWO CPUs on motherboard, o/c to same 500 (let's hear a
> big Tool Time "GHz! Arr! Arr! Arr!" grunt), NT4.0 (only service pack 1 so
> far) seeing both CPUs, times are no better- maybe even slightly slower.
>
> Have not tried multiple instances.
>
> Whuzz happnin? Where's the beef?
>
> Thanks,
>
> Matt
The official home of the Povray benchmarks is at:
http://www.haveland.com/povbench/
--
Ken Tyler
See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, POV-Ray doesn't take advantage of multiple CPU's, you will have to
use multiple copies of POV running at once to get both CPU's. But there
should be some speedup, because other programs would be put on the other
processor. Unless all non multiprocessing enabled programs are put on
one particular processor.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 18 Aug 1999 17:09:58 -0700, "Matt Swarm" <mic### [at] aol com> wrote:
>640x480 No AA
Hi, Matt. Have a look at the .url provided by Ken for the POVBench pages.
Though not an official benchmark designated by the POV-Team, it has become
the de facto standard through the years, since the time that Dan Farmer
originally wrote the scene.
I'm certain that this unofficial benchmark uses 640w by 480h and +a0.3
(anti-aliasing ON). Otherwise, your times will be misleadingly short.
--
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Swarm wrote:
> Hello:
>
> I seem to recall some discussion somewhere comparing rendering times of
> skyvase.pov as a sort of hardware benchmark (It DOES take 100% of my OS/CPU
> resources, according to Win98 System Monitor.)
>
> 640x480 No AA
>
> Using a 400 Celeron overclocked to 500, 83 MHz bus, I get skyvase times
> around 48-50 sec. ...about 5 times faster than my 233MMX.
>
> Here's the rub: using TWO CPUs on motherboard, o/c to same 500 (let's hear a
> big Tool Time "GHz! Arr! Arr! Arr!" grunt), NT4.0 (only service pack 1 so
> far) seeing both CPUs, times are no better- maybe even slightly slower.
Ummmm. Unless you grabbed the PVM patched version of POV-Ray, it should only
actually be using one of those.
NT4.0's overhead might explain a lot.
Running two instances should show you a lot.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello Folks:
Thanks for your comments and links. I checked the POVBench, compared with
the parallel section since using dual processors. Seems that my numbers
appear entirely respectable-- and that on a motherboard in use for only two
days, one whose BIOS has not yet even been tuned.
SkyVase on ABit w/ dual 400 Celeron at 500, 83 MHz bus, 128MB RAM, no BIOS
tuning.
_______________________________
_______________________________
640x480 a0.3
Instances Time Each
_______________________________
4 65.5 Single CPU Win98
2 62.25
1 63.5
_______________________________
8 30 Dual CPU NT40
6 28.7
4 28.31
2 32.6
1 65
It's clear that the dual CPU machine is at peak efficiency around FOUR
instances.
I have not yet experimented with DIVIDING the image into four sections, then
combining.
On it's face, I am unconcerned with:
--- the amount of time it will take to load programs into parallel nodes
(POV programs are ridiculously short);
--- networking the image portions to a hub for combining (100 Mb net is
nearly FREE these days, and would take all of 50 milliseconds) and for BIOS
programmers, there may totally FREE motherboard communications busses (5
times faster!) just waiting to be exploited (do the numbers 33 and 66 MHz
suggest anything?);
--- image portion combining overhead. [As implied, conveyance of the image
portions would not be significant providing the portion size is not too
fine-grained. 10ms would be huge if the renderer was only given a 20ms
job, but only a half-percent of a two-second job.] As for the Combiner Hub,
it would use RAMDisk, and should not take any longer to combine than the
nodes took to produce the imageportions.
Given this guess, if we are measuring ONE rendering, the combiner will
double the time. If however, we are averaging ONE HUNDRED renderings, it
will only add ONE PERCENT (it's doing the last job's output while the
imaging nodes are onto new mischief).
It is apparent here that *load balancing* is a pretty crucial issue. I'm a
bit more concerned about initialization times of the POV interpreter.
Another concern in real world image processing with cluster computers is
PREDICTING how long a given program will take to render, so we know how to
carve up the images so as to initiate the optimal number of instances on a
multi-CPU node (in my case 4- see above).
SCENARIO ONE:
This would be more of an issue on, say, a 10-dual-CPU-node "10 GHz"
cluster. Perhaps for continuous image production this will actually be a
nonissue. (Report the instances to the 'boss' when they get below, say,
four... and get another job. ---Non-union, I would say.--- :)
SCENARIO TWO:
Number of instances on a node would indeed *not* be a concern on, say, a
300
single-CPU cluster-- but giving each CPU a task large enough so that
communication remains a small percentage would still require predictive
analysis.
Think it's possible to gut the POV interpreter so it just combines
best-guesses as what this command and that loop will require in rendering
time? (Aw, c'mon, don't tell me there's a switch for that! :) Other
strategies?
Think of another place to post these concerns?
I have begun work on the first scenario- the dual-CPU cluster. I may do
the second... have 300 ISA backplane slots, racks, and about 50 CPU cards
for starters. But I'm looking for some old ISA card which has more
processing power and is dirt cheap- like a video card which used overkill
RISC maybe?
Ain't it FUN?
Matt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: The official home of the Povray benchmarks is at:
: http://www.haveland.com/povbench/
I still think that this benchmark has not very much relevance anymore with
current computers. If one computer renders the skyvase in 5 seconds and
other in 6 seconds, that doesn't tell anything about which one is faster.
When we talk about times this short, you can't compare computers anymore.
If you render the scene for first time it may take 10 seconds. If you then
render it again, it may take 5 seconds. Is the computer twice as fast now?
Of course not. There are several things that affect the render time
significantly when the total time is so short, for example the disk buffer,
cache, other processes, etc. You can get very varying times from one
render to another. They have no meaning. One computer may be even faster
than other even if it takes 10 seconds to render the skyvase although the
other one takes only 5. Perhaps the other one had a faster disk or whatever.
If the scene was so slow to calculate that it took about 1 minute for
the fastest computer to render it, then the results could be relevant. Then
the time really measures rendering speed. If a poor disk cache adds a couple
of seconds to the total time, that has no meaning when the total time is
over one minute.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Ken <tyl### [at] pacbellnet> wrote:
> : The official home of the Povray benchmarks is at:
> : http://www.haveland.com/povbench/
>
> I still think that this benchmark has not very much relevance anymore with
> current computers. If one computer renders the skyvase in 5 seconds and
> other in 6 seconds, that doesn't tell anything about which one is faster.
> When we talk about times this short, you can't compare computers anymore.
> If you render the scene for first time it may take 10 seconds. If you then
> render it again, it may take 5 seconds. Is the computer twice as fast now?
> Of course not. There are several things that affect the render time
> significantly when the total time is so short, for example the disk buffer,
> cache, other processes, etc. You can get very varying times from one
> render to another. They have no meaning. One computer may be even faster
> than other even if it takes 10 seconds to render the skyvase although the
> other one takes only 5. Perhaps the other one had a faster disk or whatever.
> If the scene was so slow to calculate that it took about 1 minute for
> the fastest computer to render it, then the results could be relevant. Then
> the time really measures rendering speed. If a poor disk cache adds a couple
> of seconds to the total time, that has no meaning when the total time is
> over one minute.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
I think you can eliminate the disk cache from the equation because the file
and memory overhead is so small that the scene easily loads into ram memory
even on the most poorly equipped machines. With regard to other elements
effecting render times I agree that a more robust scene should be developed
to really test the power of modern processors and ultimately their true
raytracing speed rating. I leave that task to those more competent than
myself to decide what that may be but I'm sure there must be some routines
in Pov that could be used for a reliable benchmark. Probably a combination
of math functions, high order primitives, and complex surface finishes that
require large numbers of ray intersection tests. All of this can still be
done without the need to consume large quantities of memory so that disk
swapping can be avoided on even under equipped machines.
--
Ken Tyler
See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for responding. For my interests and motivations for running these
tests, see my "Results..." posting below.
>> I still think that this benchmark has not very much relevance anymore
with
>> current computers. If one computer renders the skyvase in 5 seconds and
>> other in 6 seconds, that doesn't tell anything about which one is faster.
This has become conventional wisdom, useful if not applied too broadly. To
universalize it, however, is to err as those who apply narrow and specific
tests to a GENERAL computing machine.
To test for IMAGE RENDERING, what is better than loading a CPU(s) completely
with the software it will be running?
Given that, we are left only with choosing a test protocol which will
approximate our kind of script programs-- and, yes, this does require
judgment. Will we use fonts? Fog? Focal blur? Textures? How much of
each?
Note that my emphasis is directed from 'how fast is my machine?' to 'how
much WORK can I expect out of this machine?' They are corollaries, to be
sure, but my interest lies more in workload scalability-- or moving to 'real
time' designing. So far, I've found the results of my tests to be quite
relevant and informative.
[And, yes, for brief tests to be meaningful, one must minimize variables
like disk accesses (another program's), etc. A lovely example: in both
Win98 and NT, as quickly installed and (un)configured on my '1 GHz' test
machine, one of the four or six or eight instances of POV might run TWICE as
fast.
Turns out to be the instance which has the focus. Had to click on
desktop after starting all.
Beyond that, discarding extremes, my results were very consistant. A
percent or two.]
> With regard to other elements
>effecting render times I agree that a more robust scene should be developed
>to really test the power of modern processors and ultimately their true
>raytracing speed rating. I leave that task to those more competent than
>myself to decide what that may be but I'm sure there must be some routines
>in Pov that could be used for a reliable benchmark. Probably a combination
>of math functions, high order primitives, and complex surface finishes that
>require large numbers of ray intersection tests.
When we shift the focus from the work a particular machine will do to
TESTING CPUs and machines in general, Ken, it seems to me than NM's
criticism becomes more applicable. For example, if an x86 compiler used on
POV source is inferior to an Alpha compiler, the Alpha might look 50% faster
for certain POV programs. Clearly, we are not just testing hardware.
Matt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Swarm wrote:
> When we shift the focus from the work a particular machine will do to
> TESTING CPUs and machines in general, Ken, it seems to me than NM's
> criticism becomes more applicable. For example, if an x86 compiler used on
> POV source is inferior to an Alpha compiler, the Alpha might look 50% faster
> for certain POV programs. Clearly, we are not just testing hardware.
>
> Matt
I won't argue your point... BUT... well ok. Then the only true test
of your performance would be when it is compared to a similar system
architecture and platform running at a specific speed. Any other
comparison would simply imply that your machine is different than
someone else's and your results would therefore be misleading. It
that what you are implying ?
--
Ken Tyler
See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
