 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams <nos### [at] econym demoncouk> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>> 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 :)
>
I'm actually rendering my animations using RendView, a self-developed
tool. Not useful for still images but it can distribute frames across a
network. Lots of features.
http://www.cip.physik.uni-muenchen.de/~wwieser/ani/rendview/
BTW, as we were talking about the hardware: I was running RendView
and POVRay-3.5+own patches on a...
28-node PIV-2.4 GHz (HT) cluster
last week for the animation "Flying along Vallis Marineris on Mars"
Can recomment that :)
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Tek wrote:
>>
> 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.
>
Yes but it should be possible to find a portable interface for all the OSes.
It's like there are 3 different graphical interfaces (Mac, Windows, X11).
That should be possible for threads, too. At least Apache-2 can do it IIRC.
I think, one could consider designing POVRay-4 in a way to allow for that.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>>
>> 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...
>
You can also look at PovPVM, maybe after have read this paper:
http://www.oreilly.com/catalog/clusterlinux/chapter/ch09.html
--
http://tth.vaboofer.com/Cette/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>
> 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.
>
Just use Putty...
http://www.chiark.greenend.org.uk/~sgtatham/putty/
--
http://tth.vaboofer.com/Cette/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
> 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 :)
I could never go back to single CPU boxen :)
Just be aware that dual CPU setups can be quite picky when it comes to RAM,
so a load of your local vendors "cheap and chearfull" probably wont cut it
(check for compatability with the vendor before you buy, and make sure the
vendor will swap any RAM that fails to perform as expected, sometimes
simply switching brands can make a world of difference)
That said, I have only built one dually that had memory related problems
(random freezes, failing specific memtest86 tests) and turning off spread
spectrum in the bios cured it.
www.2cpu.com has an excellent forum.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>
> "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?
The current version of POV-Ray has a bug which causes some memory not
to be freed until the whole batch of frames is finished for a given
INI. So I limit things to 12 frames at a time (that's half a second
of animation, and all of my shots are multiples of half a second in
length).
> Have you come up with a way of handling scenes that use persistent
> variables (e.g. particle systems, physics, etc)?
Everything is calculated in the scene file from scratch for each frame.
> Have you tried a similar approach on still images?
When I do a still frame I generally have the faster machine render the
whole thing.
> 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.
The present method suits my needs.
> 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.
Probably. I have about 200 of the ini files, and the only edit I need
to do is to update the source file. There's probably a way to put
that in the command line and skip the editing.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr"> wrote:
>
> Well, you should prefer "http://openmosix.sourceforge.net/"...
>
I have tested pvmpovray35 with openMosix, and it works a treat. Overhead
might be higher than say a dedicated PVM or MPI cluster but admin is much
simpler, IMHO.
Matthew Grove
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr"> wrote in message
news:40667a7e$1@news.povray.org...
> > 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.
However, when people refer to a CPU being 32bit, they usually are referring
to the ALU. The FPU has been 80 bit since at least the '80s.
> 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.
Well, it's been a few years, but I used to do quite a bit of graphics
programming in assembly. Did you know that, for instance, the FPU registers
load so fast that games used them to load bitmaps from regular memory to
video memory? It worked about 30% faster than a standard transfer. In
fact, this was the reason MMX used the FPU registers, and so you can't use
FPU and MMX at the same time.
> 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
But they didn't. Internally, the FPU is identical between the AthlonXP, 64
and FX models.
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40686cfe$1@news.povray.org> , "Chambers"
<bdc### [at] yahoocom> wrote:
> Well, it's been a few years, but I used to do quite a bit of graphics
> programming in assembly. Did you know that, for instance, the FPU registers
> load so fast that games used them to load bitmaps from regular memory to
> video memory? It worked about 30% faster than a standard transfer. In
> fact, this was the reason MMX used the FPU registers, and so you can't use
> FPU and MMX at the same time.
That is nonsense. They are faster for copies because you execute fewer
instructions per copy and on a 64 bit bus (since the Pentium, and even with
burst transfers on a 486 bus) the maximum bandwidth is used. Further, MMX
used FPU registers simply as a kludge so operating systems and many ancient
programs would not have to be modified to save additional data when
switching contexts. This is why certain versions of Windows needed patching
later on when SSE with its additional registers was added.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40687543$1@news.povray.org...
> In article <40686cfe$1@news.povray.org> , "Chambers"
> <bdc### [at] yahoocom> wrote:
>
> > Well, it's been a few years, but I used to do quite a bit of graphics
> > programming in assembly. Did you know that, for instance, the FPU
registers
> > load so fast that games used them to load bitmaps from regular memory to
> > video memory? It worked about 30% faster than a standard transfer. In
> > fact, this was the reason MMX used the FPU registers, and so you can't
use
> > FPU and MMX at the same time.
>
> That is nonsense. They are faster for copies because you execute fewer
> instructions per copy and on a 64 bit bus (since the Pentium, and even
with
> burst transfers on a 486 bus) the maximum bandwidth is used. Further, MMX
> used FPU registers simply as a kludge so operating systems and many
ancient
> programs would not have to be modified to save additional data when
> switching contexts. This is why certain versions of Windows needed
patching
> later on when SSE with its additional registers was added.
>
> Thorsten
Well, I only surmised. Thank you for correcting me.
It's *still* a neat hack for 486 systems to up the transfer rate :)
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <bdc### [at] yahoocom> wrote:
> Did you know that, for instance, the FPU registers
> load so fast that games used them to load bitmaps from regular memory to
> video memory? It worked about 30% faster than a standard transfer.
This was a very widespread urban legend back in the time when Quake
was new.
The fact is that it's not true. You can test with pentiums of that time
that copying data from RAM to the video memory is not any faster using
the FPU (yes, I *did* test it explicitly instead of just trusting
internet rumors).
--
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" <war### [at] tagpovrayorg> wrote in message
news:40693a11@news.povray.org...
> Chambers <bdc### [at] yahoocom> wrote:
> > Did you know that, for instance, the FPU registers
> > load so fast that games used them to load bitmaps from regular memory to
> > video memory? It worked about 30% faster than a standard transfer.
>
> This was a very widespread urban legend back in the time when Quake
> was new.
> The fact is that it's not true. You can test with pentiums of that time
> that copying data from RAM to the video memory is not any faster using
> the FPU (yes, I *did* test it explicitly instead of just trusting
> internet rumors).
Well, I never had a straight pentium to test with, but I verified myself
that it was true of the 486 line (after that I went to a K6 with MMX).
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
