I'm planning to build a new system, specifically for POV rendering. My only
interest is in getting it to render pov scenes in the shortest time possible.
Budget is pretty flexible but not completely ridiculous, somewhere in the
thousands not tens of thousands of US dollars, and I'll be building the system
myself so all the money will go on components/OS.

So, what I want to know is: What hardware & OS configuration will give the
fastest povray rendering performance? And how much work would it take to get it
all running?

I'm open to options including multi-processor, multi-machine, custom pov builds,
etc... The only restriction is that the more work I need to do to get the thing
running the less likely it is I'll ever find the time to do it!

My ultimate aim is to improve my overall productivity in povray: I want to have
a fast way of rendering very complex high res still images and very long low res
animations, without needing any manual work to set the render going and retrieve
the result (i.e. if I have a PC farm it should be entirely automated so I don't
have to do any more than if I were rendering on a single machine).

One final note, I'm really not interested unless the system will be a number of
times faster than my current setup (Athlon XP 3000 overclocked to 2280MHz,
running Windows XP), which ran the POV 3.6 beta benchmark in 28 minutes.

So, what do you think? What sort of system should I build?

--
Tek
www.evilsuperbrain.com

P.S. Obviously if I do build such a system then I'd be quite happy to let other
people use it's power when I don't need it :)

Post a reply to this message

Why not buy a cheapo for $800 and render on one while composing on another?

Post a reply to this message

Because at the moment I want to render a 7800x5200 resolution image that runs at
around 15 pixels per second on my current PC. That's gonna take about a month!

The problem isn't tying up my main machine, the problem is the length of time
from the beginning to the end of a high quality render.

-- 
Tek
www.evilsuperbrain.com

"Greg M. Johnson" <gregj;-)565### [at] aolcom> wrote in message
news:406500e8@news.povray.org...
> Why not buy a cheapo for $800 and render on one while composing on another?
>
>

Post a reply to this message

Wasn't it Tek who wrote:
>I'm planning to build a new system, specifically for POV rendering. My only
>interest is in getting it to render pov scenes in the shortest time possible.
>Budget is pretty flexible but not completely ridiculous, somewhere in the
>thousands not tens of thousands of US dollars, and I'll be building the system
>myself so all the money will go on components/OS.
>
>So, what I want to know is: What hardware & OS configuration will give the
>fastest povray rendering performance? And how much work would it take to get it
>all running?
>
>I'm open to options including multi-processor, multi-machine, custom pov builds,
>etc... The only restriction is that the more work I need to do to get the thing
>running the less likely it is I'll ever find the time to do it!
>
>My ultimate aim is to improve my overall productivity in povray: I want to have
>a fast way of rendering very complex high res still images and very long low res
>animations, without needing any manual work to set the render going and retrieve
>the result (i.e. if I have a PC farm it should be entirely automated so I don't
>have to do any more than if I were rendering on a single machine).
>
>One final note, I'm really not interested unless the system will be a number of
>times faster than my current setup (Athlon XP 3000 overclocked to 2280MHz,
>running Windows XP), which ran the POV 3.6 beta benchmark in 28 minutes.
>
>So, what do you think? What sort of system should I build?

To find out what's fastest, I suggest that you take a look at the
"Official PoVRay Benchmarks" site 
<http://new.haveland.com/povbench/index.php>

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.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message
news:Nvn### [at] econymdemoncouk...
> To find out what's fastest, I suggest that you take a look at the
> "Official PoVRay Benchmarks" site
> <http://new.haveland.com/povbench/index.php>

Yes I know that site, my PC's currently ranked 20th on their single processors
list :)

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

Those benchmarks are very interesting, but they're not giving me enough
information to compare the various options, like how to set up povray with 128
CPUs!

So I was hoping some of the knowledgable folks here might be able to offer more
practical advice. I'd be very interested in hearing from people who've conducted
these very fast benchmarks and whether they think it's suitable for my purposes.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Tek wrote:
> I'm planning to build a new system, specifically for POV rendering. My only
> interest is in getting it to render pov scenes in the shortest time possible.
> Budget is pretty flexible but not completely ridiculous, somewhere in the
> thousands not tens of thousands of US dollars, and I'll be building the system
> myself so all the money will go on components/OS.
> 
> So, what I want to know is: What hardware & OS configuration will give the
> fastest povray rendering performance? And how much work would it take to get it
> all running?
> 
> I'm open to options including multi-processor, multi-machine, custom pov builds,
> etc... The only restriction is that the more work I need to do to get the thing
> running the less likely it is I'll ever find the time to do it!
> 
> My ultimate aim is to improve my overall productivity in povray: I want to have
> a fast way of rendering very complex high res still images and very long low res
> animations, without needing any manual work to set the render going and retrieve
> the result (i.e. if I have a PC farm it should be entirely automated so I don't
> have to do any more than if I were rendering on a single machine).
> 
> One final note, I'm really not interested unless the system will be a number of
> times faster than my current setup (Athlon XP 3000 overclocked to 2280MHz,
> running Windows XP), which ran the POV 3.6 beta benchmark in 28 minutes.
> 
> [...]

AMD 64bit systems (either Athlon 64 or Opteron) are probably the fastest 
single processor machines for POV-Ray at the moment.  I recently posted 
a link to a comparitive test of modern PC processors which included a 
POV-Ray test in p.off-topic.  This was running the official (32bit) 
version of POV-Ray - note that a 64bit version does not necessarily need 
to be faster.  I would not really trust the benchmark results Mike 
posted the link to because they are not verified to be correct in any way.

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.

-- 
Christoph Hormann
http://www.tu-bs.de/~y0013390/

Post a reply to this message

Mike Williams <nos### [at] econymdemoncouk> 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.

  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.

  The results might be genuine in that they show real rendering times,
but how can we be sure that they really used the proper rendering
settings when running the benchmark? If you render for example
without antialiasing you will get, surprise surprise, an enormously
faster time.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> My ultimate aim is to improve my overall productivity in povray: I want to have
> a fast way of rendering very complex high res still images and very long low res
> animations, without needing any manual work to set the render going and retrieve
> the result (i.e. if I have a PC farm it should be entirely automated so I don't
> have to do any more than if I were rendering on a single machine).

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. This additional work is not necessary 
with a single CPU and might be a reason to choose the latter one if this 
"entirely automated" workflow has such a high priority for you. 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.).
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.

My choice would be to get one dual-cpu and one single-cpu PC. The dual 
one for developing and optimising the scenes, the single one to run the 
finals (while you can go on and develop etc. on the dual one).
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 :)

HTH,
Florian

Post a reply to this message

Tek wrote:

> Because at the moment I want to render a 7800x5200 resolution image that
> runs at around 15 pixels per second on my current PC. That's gonna take
> about a month!
> 
> The problem isn't tying up my main machine, the problem is the length of
> time from the beginning to the end of a high quality render.

<neo>Deja vu</neo>

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

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

Wasn't it Warp who wrote:
>Mike Williams <nos### [at] econymdemoncouk> 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

Mike Williams a écrit :
> 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

I'm getting confused, what system are you saying I should buy?

-- 
Tek
www.evilsuperbrain.com

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

For doing long animations you can eat your heart out at the Internet Movie
Project. I myself have rendered animations there and it's very powerful.
www.imp.org

Post a reply to this message

Tek wrote:
> 
> So, what do you think? What sort of system should I build?
> 
	http://www.top500.org/

Post a reply to this message

Tek wrote:

> 
> Has anyone attempted such a thing? Is there software/OS's available that will
> let a network of PCs emulate a multi-processor system? 

      may be http://www.mosix.org/ ?

Post a reply to this message

"Thierry Boudet" <oul### [at] chezcom> wrote in message
news:40660c4c$1@news.povray.org...
> Tek wrote:
> > Has anyone attempted such a thing? Is there software/OS's available that
will
> > let a network of PCs emulate a multi-processor system?
>
>       may be http://www.mosix.org/ ?

Ooh, that looks interesting!
Now all I need is a parallel processing version of POV and lots of PCs...

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Hmm. just had a thought.. There is a program called Synergy out that lets 
you control two networked machines with the same keyboard and mouse. 
There is an article on TechTV about it at:

http://www.techtv.com/screensavers/downloadoftheday/story/0,24330,3647418
,00.html

This might actually make managing two or more machines easier. It runs on 
both Windows and Linux. Haven't tried it myself, but then I haven't got 
anything networked to try it with. It definitely looked interesting 
though.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

"Tek" <tek### [at] evilsuperbraincom> wrote in news:406601ba$1@news.povray.org:

> I'm getting confused, what system are you saying I should buy?
> 

Amiga ;)

-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

Tom Galvin a écrit :
> "Tek" <tek### [at] evilsuperbraincom> wrote in news:406601ba$1@news.povray.org:
> 
> 
>>I'm getting confused, what system are you saying I should buy?
>>
> 
> 
> Amiga ;)
> 

Yeah! Amiga rules!!!

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

> "Thierry Boudet" <oul### [at] chezcom> wrote in message
> news:40660c4c$1@news.povray.org...
> 
>>Tek wrote:
>>
>>>Has anyone attempted such a thing? Is there software/OS's available that
> 
> will
> 
>>>let a network of PCs emulate a multi-processor system?
>>
>>      may be http://www.mosix.org/ ?
> 
> 
> Ooh, that looks interesting!
> Now all I need is a parallel processing version of POV and lots of PCs...
> 

Well, you should prefer "http://openmosix.sourceforge.net/"...

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

Even better!

-- 
Tek
www.evilsuperbrain.com

"laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr"> wrote in message
news:406674fd@news.povray.org...
> > "Thierry Boudet" <oul### [at] chezcom> wrote in message
> > news:40660c4c$1@news.povray.org...
> >
> >>Tek wrote:
> >>
> >>>Has anyone attempted such a thing? Is there software/OS's available that
> >
> > will
> >
> >>>let a network of PCs emulate a multi-processor system?
> >>
> >>      may be http://www.mosix.org/ ?
> >
> >
> > Ooh, that looks interesting!
> > Now all I need is a parallel processing version of POV and lots of PCs...
> >
>
> Well, you should prefer "http://openmosix.sourceforge.net/"...
>
> Regards,
>
> -- 
> Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

Interesting, though I'm not sure that it really saves me much work since the
more difficult thing is farming out rendering of *different* sections of the
scene...

In fact, what I'd want would be a way to execute pov remotely on a linux machine
by invoking it from my windows machine.

-- 
Tek
www.evilsuperbrain.com

"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1acfe5462ad64919899fa@news.povray.org...
> Hmm. just had a thought.. There is a program called Synergy out that lets
> you control two networked machines with the same keyboard and mouse.
> There is an article on TechTV about it at:
>
> http://www.techtv.com/screensavers/downloadoftheday/story/0,24330,3647418
> ,00.html
>
> This might actually make managing two or more machines easier. It runs on
> both Windows and Linux. Haven't tried it myself, but then I haven't got
> anything networked to try it with. It definitely looked interesting
> though.
>
> -- 
> void main () {
>   If Schrödingers_cat is alive
>     call functional_code()
>   else
>     call crash_windows();
> }

Post a reply to this message

>   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

Well, you seems to mix CPU and ALU:
ALU stands for Arithmetic and Logic Unit. It is the part of the chip 
that compute on integers.
The ALU and the FPU are separate, but are both inside the CPU.

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

Well, to know this for sure, we'll have to find an assembler programmer 
which will be able to say if it is possible to load one of the FPU 
register directly from the cache in the same number of cycles the other 
registers do.
If so, then the speed difference between the Athlon-XP and the Athlon-64 
is partly (they can also have improved the FPU unit...) because the last 
one can use ALL the registers to store 64 bits data, instead of the 
lower number of FPU registers and then require the cache, which is slower.

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

Tek wrote:
> But I thought POV doesn't support dual CPUs?
> 

Running POV-Ray on a multiprocessor system would be the same as running 
on several independent machines - you would start several render 
processes for using all available processors.

-- 
Christoph Hormann
http://www.tu-bs.de/~y0013390/

Post a reply to this message

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

This has been discussed a lot already - first of all a use of 
multithreading inside POV-Ray will not have any significant advantage 
for distributed renders on a cluster of several machines - even if you 
use a system emulating a single multiprocessor machine the communication 
overhead would require a completely different design than on a true SMP 
machine (and you would have the same trouble with techniques that are 
difficult to parallelize as with an external implementation).

But much more important is that there is no way to implement 
multithreading in a portable manner - not even for the three 'official' 
platforms.  So if you want to attempt implementing such a system (which 
would be pretty hard on the current POV-Ray source anyway) you would 
have to implement several platform specific variants.

-- 
Christoph Hormann
http://www.tu-bs.de/~y0013390/

Post a reply to this message

Christoph Hormann wrote:
> Running POV-Ray on a multiprocessor system would be the same as running
> on several independent machines - you would start several render
> processes for using all available processors.

And hope your not using radioasity....

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

> But I thought POV doesn't support dual CPUs?

It doesn't, but you will be able to render 2 halfs of an image (depending on
image) or 2 images, or render on one cpu and still be able to use the PC as
normal.

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

Yes, I get the point now. If I'm going for a multi-PC system it's actually
cheaper to have half as many PCs all with dual processors. That's some good
advice and I'm currently checking the online shops to figure out where the sweet
spot is between speed and money :)

-- 
Tek
www.evilsuperbrain.com

"Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
news:4066a47c@news.povray.org...
> > But I thought POV doesn't support dual CPUs?
>
> It doesn't, but you will be able to render 2 halfs of an image (depending on
> image) or 2 images, or render on one cpu and still be able to use the PC as
> normal.
>
> -- 
> 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

laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> >   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

> Well, you seems to mix CPU and ALU:

  No, I'm not. We were discussing whether the FPU can handle chunks of
data larger than 32 bits. You claimed that the *FPU* of Athlon XP can't
because it's internally 32-bit. I casted doubt about this. As an argument
you said that the CPU and the ALU of Athlon XP is 32 bits architecture.
I commented that the FPU has nothing to do with those.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Among other things, "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"?
> 
> 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.

Maybe "Even though the Athlon-XP's FPU ..." would be more appropriate? :)

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

>   No, I'm not. We were discussing whether the FPU can handle chunks of
> data larger than 32 bits. You claimed that the *FPU* of Athlon XP can't
> because it's internally 32-bit. I casted doubt about this. As an argument

Well, re-read my posts: I _NEVER_ SAID THAT THE _FPU_ WAS 32 BITS!

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

>>>>Even if the Athlon-XP's FPU is able to use 64 bits double precision
>>>>floats
> 
> 
> Maybe "Even though the Athlon-XP's FPU ..." would be more appropriate? :)
> 

Thanks.

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

Among other things, Tek wrote:

> So, what I want to know is: What hardware & OS configuration will give the
> fastest povray rendering performance? And how much work would it take to
> get it all running?

If you're going to use this system only for rendering, I'd probably go for a 
linux (or similar) machine, where you can disable all kinds of processes 
and servers not needed. Besides, you don't really need an expensive 
3D-videocard, or a 5.1-soundcard, or a flat monitor... just some processor, 
ram and HD, and a netcard. You can control this machine through the net and 
use some KVM switch when needed.

Now, I guess you would need a good compiler too... So, I'd narrow the 
question to: what combination of processor and compiler would give the best 
performance for under linux?

But I'm no expert... :)

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Rick [Kitty5] wrote:
> Christoph Hormann wrote:
> 
>>Running POV-Ray on a multiprocessor system would be the same as running
>>on several independent machines - you would start several render
>>processes for using all available processors.
> 
> And hope your not using radioasity....
> 

No, you just have to understand how radiosity works to be able to 
distribute the render efficiently.

A good example for this being a usable technique for radiosity renders 
as well is:

http://astronomy.swin.edu.au/~pbourke/povray/night/

-- 
Christoph Hormann
http://www.tu-bs.de/~y0013390/

Post a reply to this message

> Have you come up with a way of handling scenes that use persistent variables
> (e.g. particle systems, physics, etc)?
It is clear that for such systems a frame can only be rendered if his 
predecessor has already been done (or say the part modifying persistent 
variables, i.e. parsing). This is of course totally in contrast with the 
original idea of seperating the workload on multiple POV-instances. I 
ran into a similar problem with an animation I'm working on which will 
be rendered on the IMP farm (http://www.imp.org). The only way to handle 
the situation was to change the scene not to use file-i/o (i.e. 
persistent variables) at all.
Another approach which could work in many cases is to seperate 
simulation from rendering: First, calculate the persistent variables and 
save them in a frame-dependent include file (this must be done in a 
single machine, of course). Then distribute this data among your render 
clients (or make sure they can access it somehow) and render a second 
pass using the data generated before. This would be a good idea if the 
calculation of the persistent variables does not take too much time 
compared to the rendering itself. (You can compare this method with a 
two-pass rendering for splitted radiosity renders).

> Have you tried a similar approach on still images?
Would be pretty the same IMHO, simply do not hand out frames via 
INI-files but parts of the image using +SR, +ER, +SC and +EC command 
line switches.

If you are using Windows, you should take a look at SMPOV:
http://www.it-berater.org/smpov.htm
A freeware tool for distributed POV-rendering for Windows.

Another option would be POV-Anywhere by Christoph Hormann 
(http://www-public.tu-bs.de:8080/~y0013390/povany/index.html) which 
works on many platforms (including Windows using cygwin).

For animations there is also the Internet Movie Project (www.imp.org). 
The server/client software is ported to Perl currently, so it works on 
Windows and Linux, too (Current server is Windows only).

HTH,
Florian

Post a reply to this message

laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> Well, re-read my posts: I _NEVER_ SAID THAT THE _FPU_ WAS 32 BITS!

  Direct quote from your post:

"Even if the Athlon-XP's FPU is able to use 64 bits double precision
floats, it's internal structure is only 32 bits"

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

Warp a écrit :
> laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> 
>>Well, re-read my posts: I _NEVER_ SAID THAT THE _FPU_ WAS 32 BITS!
> 
> 
>   Direct quote from your post:
> 
> "Even if the Athlon-XP's FPU is able to use 64 bits double precision
> floats, it's internal structure is only 32 bits"
> 

It has already been said, I did not use the correct phrasing, and I 
corrected it in the next post.
I was meaning the global Athlon-XP was 32 bits EXCEPT for the FPU, which 
could use 64 bits (an even more)

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

> If you are using Windows, you should take a look at SMPOV:
> http://www.it-berater.org/smpov.htm
> A freeware tool for distributed POV-rendering for Windows.
>
> Another option would be POV-Anywhere by Christoph Hormann
> (http://www-public.tu-bs.de:8080/~y0013390/povany/index.html) which
> works on many platforms (including Windows using cygwin).

That looks pretty useful :)

Thanks!
-- 
Tek
www.evilsuperbrain.com

"Florian Brucker" <tor### [at] torfboldcom> wrote in message
news:4066cc96$1@news.povray.org...
> > Have you come up with a way of handling scenes that use persistent variables
> > (e.g. particle systems, physics, etc)?
> It is clear that for such systems a frame can only be rendered if his
> predecessor has already been done (or say the part modifying persistent
> variables, i.e. parsing). This is of course totally in contrast with the
> original idea of seperating the workload on multiple POV-instances. I
> ran into a similar problem with an animation I'm working on which will
> be rendered on the IMP farm (http://www.imp.org). The only way to handle
> the situation was to change the scene not to use file-i/o (i.e.
> persistent variables) at all.
> Another approach which could work in many cases is to seperate
> simulation from rendering: First, calculate the persistent variables and
> save them in a frame-dependent include file (this must be done in a
> single machine, of course). Then distribute this data among your render
> clients (or make sure they can access it somehow) and render a second
> pass using the data generated before. This would be a good idea if the
> calculation of the persistent variables does not take too much time
> compared to the rendering itself. (You can compare this method with a
> two-pass rendering for splitted radiosity renders).
>
> > Have you tried a similar approach on still images?
> Would be pretty the same IMHO, simply do not hand out frames via
> INI-files but parts of the image using +SR, +ER, +SC and +EC command
> line switches.
>
> If you are using Windows, you should take a look at SMPOV:
> http://www.it-berater.org/smpov.htm
> A freeware tool for distributed POV-rendering for Windows.
>
> Another option would be POV-Anywhere by Christoph Hormann
> (http://www-public.tu-bs.de:8080/~y0013390/povany/index.html) which
> works on many platforms (including Windows using cygwin).
>
> For animations there is also the Internet Movie Project (www.imp.org).
> The server/client software is ported to Perl currently, so it works on
> Windows and Linux, too (Current server is Windows only).
>
> HTH,
> Florian
>

Post a reply to this message

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

Actually I've been looking into some prices, and the extra cost of the
motherboard is pretty substantial. The cheapest dual processor motherboard I
could find was over $200, whereas I found a single processor one that was
roughly equivalent for under $50. Plus the CPUs are more expensive. In fact it
works out that a dual processor system would cost me around $700 to build, and
be only slightly more than twice as fast as a system I could build for under
$200 (based on the results on the pov benchmarks site). I tried a variety of
different multi-processor setups (Athlon MP, and two different Opteron setups)
but in every case the extra processing power was outweighed by the extra cost.
So I think I'm better off with lots of very cheap systems.

-- 
Tek
www.evilsuperbrain.com

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, it's internal structure is only 32 bits"

> It has already been said, I did not use the correct phrasing, and I 
> corrected it in the next post.
> I was meaning the global Athlon-XP was 32 bits EXCEPT for the FPU, which 
> could use 64 bits (an even more)

  I thought "it" referred to "FPU"... :)

  By the way, it's "its", not "it's".
  The latter means "it is", and "it is internal structure is only 32 bits"
doesn't make sense. :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> 
>   By the way, it's "its", not "it's".
>   The latter means "it is", and "it is internal structure is only 32 bits"
> doesn't make sense. :)
> 

Oh!
Thanks for pointing that. I usually don't make that kind of error.
I'll have to be more careful when I type...

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message