 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Warp who wrote:
>Mike Williams <nos### [at] econym demoncouk> wrote:
>> The figures there are for the POV 3.5 benchmark and go as low as
>> 11 mins 7 for a single CPU and 1 minute 12 for 128 CPUs in parallel.
>
> How reliable those results are? What measures, if any, do the maintainers
>of the site take to verify that the results are genuine?
>
> For example, I find it difficult to believe that a 1GHz Itanium2 is
>almost twice faster than a 3GHz P4, a 2.8GHz Xeon or a 2.5GHz Athlon XP
>(specially considering that it's the *only* entry using an itanium, so
>we don't have comparable times with other itanium systems).
> If the result is genuine, I would certainly like to know how it is
>possible.
Most of the math used in POV is floating point. An Itanium 2 clains to
run at 1.2 cycles per floating point operation. Various models of
Pentium 4 claim to run at between 6.0 and 6.9 cycles per flop. Various
models of Pentium 3 Xeon claim to run at between 3.3 and 4.7 cycles per
flop. An Athlon XP claims to run at 4.3 cycles per flop.
So, theoretically,
1GHz Itanium 2 should perform a GigaFLOP in 1.3 seconds
3GHz Pentium 4 should perform a GigaFLOP in 2.0 to 2.3 seconds
2.8GHz Xeon should perform a GigaFLOP in 1.2 to 1.7 seconds
2.5GHz Athlon XP should perform a GigaFLOP in 1.7 seconds
> There are many other entries which are difficult to believe as well.
>For example a 1.8GHz Opteron being faster than a 2.5GHz Athlon XP.
1.8GHz Opteron @ 3.6 cycles per flop = GigaFLOP in 2.0 seconds
All other things being equal, one might expect the Athlon to be a little
faster than the Operon (assuming we can trust the claimed cycles per
flop figures). However, other things are never quite equal. For example
the fact that the Opteron is listed as running Linux and the Athlon as
running Windows XP will have made some difference. Things like cache
sizes and memory speeds may also have an effect.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>
> So, what do you think? What sort of system should I build?
You aren't going to get much better performance out of a single box;
multi-machine rendering is your solution.
Render management on multiple machines is not that difficult. I have
two WinXP boxes here (one's a laptop). I have one directory on one
machine shared out, and both machines map it as drive P:. POV-Ray on
both machines is set to look at drive P:, and all frames are written
to that drive. This way I have only one copy of the sources to worry
about, and only one place to look for rendered frames.
Rendering itself is done with a set of .ini files, each of which
designates a 12-frame set of frames to render. When I want to render
a large batch, I load the .ini into the render queues; I give more to
the faster box than to the slower box (about a 3:2 ratio). When the
frames are all done, they're all in one place and I can handle them as
with a single-box rendering set-up.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams <nos### [at] econymdemoncouk> wrote:
> So, theoretically,
> 1GHz Itanium 2 should perform a GigaFLOP in 1.3 seconds
> 2.8GHz Xeon should perform a GigaFLOP in 1.2 to 1.7 seconds
Yet in the benchmark results the itanium was about twice faster than
the xeon...
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Most of the math used in POV is floating point. An Itanium 2 clains to
> run at 1.2 cycles per floating point operation. Various models of
> Pentium 4 claim to run at between 6.0 and 6.9 cycles per flop. Various
> models of Pentium 3 Xeon claim to run at between 3.3 and 4.7 cycles per
> flop. An Athlon XP claims to run at 4.3 cycles per flop.
>
> So, theoretically,
> 1GHz Itanium 2 should perform a GigaFLOP in 1.3 seconds
> 3GHz Pentium 4 should perform a GigaFLOP in 2.0 to 2.3 seconds
> 2.8GHz Xeon should perform a GigaFLOP in 1.2 to 1.7 seconds
> 2.5GHz Athlon XP should perform a GigaFLOP in 1.7 seconds
>
Hey! That's interesting!
Where did you find those info?
>> There are many other entries which are difficult to believe as well.
>>For example a 1.8GHz Opteron being faster than a 2.5GHz Athlon XP.
> 1.8GHz Opteron @ 3.6 cycles per flop = GigaFLOP in 2.0 seconds
>
> All other things being equal, one might expect the Athlon to be a little
> faster than the Operon (assuming we can trust the claimed cycles per
> flop figures). However, other things are never quite equal. For example
> the fact that the Opteron is listed as running Linux and the Athlon as
> running Windows XP will have made some difference. Things like cache
> sizes and memory speeds may also have an effect.
>
You may also say that POV floating point operations are all on double
precision: 64 bits.
Even if the Athlon-XP's FPU is able to use 64 bits double precision
floats, it's internal structure is only 32 bits, so it need more time in
the Athlon-XP to feed the FPU with it's needed 64 bits data than the
Opteron, which has a 64 bits internal structure.
Regards,
--
Laurent ARTAUD (lau### [at] freefr)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> Even if the Athlon-XP's FPU is able to use 64 bits double precision
> floats
What do you mean "if"?
> it's internal structure is only 32 bits
Says who? Do you have any links or other references to corroborate this?
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But I thought POV doesn't support dual CPUs?
--
Tek
www.evilsuperbrain.com
"Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
news:406582b6@news.povray.org...
> Christoph Hormann wrote:
> > For multiprocessor machines and clusters you have a large number of
> > possible solutions but a fast multiprocessor system will usually be
> > quite expensive in comparison to a set of several inexpensive single
> > processor computers.
>
> For dual CPU boxen, aside from the cost of the extra CPU and a little more
> on the motherboard its not as bad as you would think. Significantly cheaper
> than 2 computers!
>
> Once you go over 2 CPU's then your into server land and prices do get very
> silly very quickly.
>
> --
> Rick
>
> Kitty5 NewMedia http://Kitty5.com
> POV-Ray News & Resources http://Povray.co.uk
> TEL : (+44) 0845 1083740 - ICQ : 15776037
>
> PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you, that's some very good advice :)
> Keep in mind that if you want to render radiosity scenes on multiple
> machines (or multiple processors meaning multiple instances of POV)
> you'll have to do a first pass render to get the radiosity render which
> will be used for the final trace.
That's true if I follow the philosophy of running seperate instances of pov on
seperate machines, but surely it would be possible to modify POV to run in some
multi-threaded configuration (say with each ray on a seperate thread) which
could then be farmed out to the different processors?
Has anyone attempted such a thing? Is there software/OS's available that will
let a network of PCs emulate a multi-processor system? I confess I've never
programmed anything like that and I've never looked at POV's source, so I'd be
very curious to know how difficult it would be to do something like that.
> Keep
> also in mind that a multiple-CPU/PC-environment *almost* always means
> more work, both in setting it up and keeping it running (even with
> automated software installation scripts etc.).
That side of things doesn't worry me so much. Keeping my current PC running
takes a tiny amount of my time, and provided I clone my other systems I should
only ever have to repeat the same process on all of them when I need to update
something, which is not really a big problem.
> OTOH, a dual-CPU system could be used for single CPU traces on the one
> CPU and developing scenes on the second CPU, so in that case it would
> improve your workflow.
I don't currently find my workflow is held up too badly by running high detail
renders in the background, since pov's happy to run multiple instances and most
of the time when I'm editing a scene I'm really just using a text editor (my
preview renders are very fast so don't really take much render time away from
the big render). The problem is more that if I'm working on one scene I don't
want to edit it at the same time as doing a hi-res render, because I'll only
start that hi-res render in order to find the errors that weren't showing up in
the previews. i.e. I don't have any more editing to do until I see the finished
image. Hence I want a shorter time from start to end of a render.
> Of course the CPU is not the only thing that'll make your system fast.
> Raid systems for disc access, good RAM, etc. will be important, too, but
> I guess you know that already :)
Yes I do :) I currently have 2GB of Corsair PC3200 RAM running at 350MHz (in
sync with my overclocked FSB), and it made a huge difference to render times.
I've also upgraded to the fastest CPU my motherboard can support, and I'm
looking into getting a striped RAID setup with 2 Raptor drives in the near
future. Although to be honest POV doesn't really seem to hit the hard disc too
much on most of my slow scenes, but it will be good for animations.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"John VanSickle" <evi### [at] hotmailcom> wrote in message
news:4065ABF4.A37B0EC5@hotmail.com...
> Tek wrote:
> >
> > So, what do you think? What sort of system should I build?
>
> You aren't going to get much better performance out of a single box;
> multi-machine rendering is your solution.
Hmm... interesting. It's good to hear from someone who actually uses a
multi-machine system in a practical way! :)
Certainly that sounds like a reasonably good solution to distributing animations
across machines, but it raises a few questions:
You say you have ini files to render 12 frames and you give more ini files to
the faster machine, why not simply have one ini file for each machine which
renders more frames on the faster machine than the slow one?
Have you come up with a way of handling scenes that use persistent variables
(e.g. particle systems, physics, etc)?
Have you tried a similar approach on still images?
Have you tried partially automating the management side of things? So an
automated process could watch the frames coming in and farm the next batch out
to whichever machine is currently further ahead.
Still, it sounds like it may be less effort than I feared. Plus it would be very
easy to write a program/script that could automatically generate those ini
files.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>Even if the Athlon-XP's FPU is able to use 64 bits double precision
>>floats
>
>
> What do you mean "if"?
Ah?
Sorry, I'm not a native English speaker, so I may have used the wrong
saying.
I was NOT trying to say that I do not think the FPU able to work on 64
bits double precision floats. In fact, I KNOW that it can work on 80
bits long double floats, as any x87 compatible FPU must.
>
>>it's internal structure is only 32 bits
>
>
> Says who? Do you have any links or other references to corroborate this?
>
Well, I just had a quick look at the Athlon-XP white papers. There are
no references about the registers' size.
BUT, being a x86 compatible processor, it MUST have 32 bits registers
and ALU. Using 64 bits registers with a 32 bits ALU is STUPID, so if the
Athlon-XP had been build with 64 bits registers and ALU, be sure that
they would have advertised about it (just as they are now about the
Athlon-64...).
Regards,
--
Laurent ARTAUD (lau### [at] freefr)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> BUT, being a x86 compatible processor, it MUST have 32 bits registers
> and ALU. Using 64 bits registers with a 32 bits ALU is STUPID, so if the
> Athlon-XP had been build with 64 bits registers and ALU, be sure that
> they would have advertised about it (just as they are now about the
> Athlon-64...).
This is true for the *CPU*. However, it's not the CPU which handles
the floating point code, but the FPU.
The FPU is completely separate from the CPU. The FPU has eight 80-bit
registers and it performs all floating point operations on them. I don't
know, however, if the FPU is able to load 64 and 80-bit floats directly
from memory, but I wouldn't be surprised if it could (actually I'm not
sure how wide the memory bus is in athlons, but I would be surprised
if it was narrower than 64 bits).
My point was, thus, that the CPU being a 32-bit architecture doesn't
necessarily mean the FPU is limited to handling only 32 bits wide
values at a time.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
