 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
DocJunioR nous apporta ses lumieres ainsi en ce 2004-10-05 03:41... :
>Hi.
>
>I'm using POV on a P4 machine with 3.2 GHz under winXP.
>Switching the render priority to highest, i only get a processor usage of
>50%.
>P4 processors are splitted into 2 processors. how can I tell my POV to use
>both parts?
>
>Greetz from Germany!
>DjR
>
>
>
>
>
It is possible to disable hypertreading. It must be somewhere in the
bios settings. I saw some benchmarks results that where faster with it
disabled.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is interesting. On my Athlon XP 2000+ the CPU usage
goes straight to 100% and stays there until the image is done.
At least with the AMD processor Windows XP reports
accurately ;-)
H
"Warp" <war### [at] tag povrayorg> wrote in message
news:4187ff7e@news.povray.org...
> regdo <reg### [at] wanadoofr> wrote:
> > Do you mean there is no way for POV to use the whole power of the
processor
> > and we have to wait twice the time we should ? Rats !
>
> Didn't you read what he said?
>
> P4 is just one processor, not two, and POV-Ray is using (almost) 100% of
> its power.
> You will not get basically any advantage by rendering in two threads
> because the two threads will mostly be interleaved by the CPU, not run
> in parallel.
> That is, in other words: Even if you run two instances of POV-Ray,
> each one rendering half of the image, the total rendering time will
> not speed up considerable. One instance is already using the maximum
> capacity of the CPU.
>
> Now, P4 has this funny thing called hyperthreading which makes the
> processor look like two and can, with some tricks, be used to speed up
> a program (almost as if it was run by two true processors). The trick
> is to create two threads and run eg. integer math in one (calculated
> by the ALU) and floating point math (calculated by the FPU) or MMX math
> (calculated by the MMX processor) in the other.
> However, POV-Ray can hardly use this trick even if it wanted to because
> most of what it does is floating point math, and there's only one FPU to
> do it. And POV-Ray *is* running through the FPU at full power.
>
> Windows makes it look like it is only using 50% of CPU because P4 is
> emulating two CPUs and Windows makes a simple (but basically wrong)
> calculation about how much of the two (virtual) processors POV-Ray is
> using. POV-Ray cannot use the "other processor" because there's no
> other processor. It's just a kind of "virtual" processor (which another
> process not needing the FPU could perhaps use).
>
> So no, if the POV-Ray benchmark is being finished in 30 minutes in
> your P4, there's no way it can finish in 15 minutes no matter what you
> do. That's not what the "two processors" mean.
>
> --
> #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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Harold <bai### [at] 3dculturecom> wrote:
> This is interesting. On my Athlon XP 2000+ the CPU usage
> goes straight to 100% and stays there until the image is done.
> At least with the AMD processor Windows XP reports
> accurately ;-)
How many processors do you see in the task manager? One.
With P4 you see two.
It's not about accuracy.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well it is accurate anyway ;-)
"Warp" <war### [at] tagpovrayorg> wrote in message
news:41b169a5@news.povray.org...
> Harold <bai### [at] 3dculturecom> wrote:
> > This is interesting. On my Athlon XP 2000+ the CPU usage
> > goes straight to 100% and stays there until the image is done.
> > At least with the AMD processor Windows XP reports
> > accurately ;-)
>
> How many processors do you see in the task manager? One.
> With P4 you see two.
>
> It's not about accuracy.
>
> --
> #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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> regdo <reg### [at] wanadoofr> wrote:
> > Do you mean there is no way for POV to use the whole power of the processor
> > and we have to wait twice the time we should ? Rats !
>
> Didn't you read what he said?
>
> P4 is just one processor, not two, and POV-Ray is using (almost) 100% of
> its power.
> You will not get basically any advantage by rendering in two threads
> because the two threads will mostly be interleaved by the CPU, not run
> in parallel.
> That is, in other words: Even if you run two instances of POV-Ray,
> each one rendering half of the image, the total rendering time will
> not speed up considerable. One instance is already using the maximum
> capacity of the CPU.
>
> Now, P4 has this funny thing called hyperthreading which makes the
> processor look like two and can, with some tricks, be used to speed up
> a program (almost as if it was run by two true processors). The trick
> is to create two threads and run eg. integer math in one (calculated
> by the ALU) and floating point math (calculated by the FPU) or MMX math
> (calculated by the MMX processor) in the other.
> However, POV-Ray can hardly use this trick even if it wanted to because
> most of what it does is floating point math, and there's only one FPU to
> do it. And POV-Ray *is* running through the FPU at full power.
>
> Windows makes it look like it is only using 50% of CPU because P4 is
> emulating two CPUs and Windows makes a simple (but basically wrong)
> calculation about how much of the two (virtual) processors POV-Ray is
> using. POV-Ray cannot use the "other processor" because there's no
> other processor. It's just a kind of "virtual" processor (which another
> process not needing the FPU could perhaps use).
>
> So no, if the POV-Ray benchmark is being finished in 30 minutes in
> your P4, there's no way it can finish in 15 minutes no matter what you
> do. That's not what the "two processors" mean.
>
> --
> #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 -
That's not quite completely correct. A P4 with hyperthreading is a single
physical processor but two logical processors. Logical and virtual are not
to be confused. Long story short while it's true the two logical
processors do share some of their physical resources so it's not true SMP,
it's fairly close in most aspects due to the way the pipeline is designed.
It's more than emulation. Overall it's a more efficient processor
(assuming you have software that can utilize it). So when windows is
reporting that it's only using 50% of it resources that's mostly true and
also why you can run other programs without lagging them or POV (POV keeps
utilizing it's full logical processor while the other programs use
resources from the other).
Actual benchmarks have shown that if you run 2 instances of POVRay on a
hyperthreading machine (one instance on each logical processor, each
rendering half your image) you will have the completed image in around half
the time (assuming the two halfs take about the same time to render).
Try SMPov (I use it with my render farms and it works pretty good), it's
fairly easy to set up and run. The one downside to this sort of thing is
when you're doing radiosity you can get seams where the images were put
together and with photons I'd suggest saving a photon map and loading it to
save on preprocessing time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mienai <Mienai> wrote:
> Actual benchmarks have shown that if you run 2 instances of POVRay on a
> hyperthreading machine (one instance on each logical processor, each
> rendering half your image) you will have the completed image in around half
> the time (assuming the two halfs take about the same time to render).
I find that hard to believe. Either that is not true, or the claim
that two processes can't use the FPU at the same time is not true.
If I'm not mistaken, one POV-Ray thread could perform integer math
at the same time the other POV-Ray thread is performing FPU math. But
when the first one needs the FPU it has to wait for the second. Since
POV-Ray uses the FPU quite heavily, I find it quite hard to believe
that running it in two threads would drop the rendering time to half
(unless the P4 *really* can run two FPU threads at the same time).
I am ready to believe that the total rendering time drops by
some percentage (because POV-Ray naturally performs other operations
than just FPU opcodes, naturally), but I would be surprised if this
percentage would be anything close to 50%.
If it really is close to 50%, then someone has to explain me how
is that possible.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mienai nous apporta ses lumieres en ce 2005-02-01 04:41:
>
> That's not quite completely correct. A P4 with hyperthreading is a single
> physical processor but two logical processors. Logical and virtual are not
> to be confused. Long story short while it's true the two logical
> processors do share some of their physical resources so it's not true SMP,
> it's fairly close in most aspects due to the way the pipeline is designed.
> It's more than emulation. Overall it's a more efficient processor
> (assuming you have software that can utilize it). So when windows is
> reporting that it's only using 50% of it resources that's mostly true and
> also why you can run other programs without lagging them or POV (POV keeps
> utilizing it's full logical processor while the other programs use
> resources from the other).
>
> Actual benchmarks have shown that if you run 2 instances of POVRay on a
> hyperthreading machine (one instance on each logical processor, each
> rendering half your image) you will have the completed image in around half
> the time (assuming the two halfs take about the same time to render).
>
> Try SMPov (I use it with my render farms and it works pretty good), it's
> fairly easy to set up and run. The one downside to this sort of thing is
> when you're doing radiosity you can get seams where the images were put
> together and with photons I'd suggest saving a photon map and loading it to
> save on preprocessing time.
>
>
I've seen benchmarks results that point to a possible preformance *improvement* by
disabling
hyperthreading.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Mienai <Mienai> wrote:
> > Actual benchmarks have shown that if you run 2 instances of POVRay on a
> > hyperthreading machine (one instance on each logical processor, each
> > rendering half your image) you will have the completed image in around half
> > the time (assuming the two halfs take about the same time to render).
>
> I find that hard to believe. Either that is not true, or the claim
> that two processes can't use the FPU at the same time is not true.
>
> If I'm not mistaken, one POV-Ray thread could perform integer math
> at the same time the other POV-Ray thread is performing FPU math. But
> when the first one needs the FPU it has to wait for the second. Since
> POV-Ray uses the FPU quite heavily, I find it quite hard to believe
> that running it in two threads would drop the rendering time to half
> (unless the P4 *really* can run two FPU threads at the same time).
> I am ready to believe that the total rendering time drops by
> some percentage (because POV-Ray naturally performs other operations
> than just FPU opcodes, naturally), but I would be surprised if this
> percentage would be anything close to 50%.
> If it really is close to 50%, then someone has to explain me how
> is that possible.
>
> --
> #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 -
So I ran the POVRay benchmark today on my P4 system and here's the results:
single thread running entire benchmark:
average 71 PPS in 0d 00h 34m 35s
two simulataneous threads, each running half benchmark (verticle split):
thread 1: average 52 PPS in 0d 00h 09m 45s
thread 2: average 48 PPS in 0d 00h 10m 49s
two simulataneous threads, each running half benchmark (verticle split),
photons precalculated:
thread 1: average 60 PPS in 0d 00h 08m 27s
thread 2: average 54 PPS in 0d 00h 09m 30s
single thread, hyperthreading disabled:
average 74 PPS in 0d 00h 33m 05s
So looking at those results it would appear that I was wrong, that it's
actually closer to a third the time. Speaking from experience though I
generally find that it's closer to 50% on most the larger files (a 16hr
render taking closer to 8hr than 5). I took a graduate class on super
scalar architecture last year but we didn't talk about FPU's specifically
much but if I had to guess it has to do with the way it's pipelined, plus
if I remember right the FPU is opperated twice as fast as the CPU core (it
can do a calculation every half tic). I don't know how much you know about
the subject but pipelining increases efficiency, it sucks for doing small
opperations but when your doing a whole series of operations it kicks ass.
You can start the next before the first is complete. I hope that answers
your questions, if you have more feel free to ask.
If you do something like this I highly recommend precalculating photons and
loading the map file so you don't have to calculate it for each thread you
run (decreases overhead)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> I've seen benchmarks results that point to a possible preformance *improvement* by
disabling
> hyperthreading.
>
> Alain
I'm sure it's possible that there could be an improvement, but my results
went the other way. Maybe My mobo doesn't properly set the CPU in the
correct mode when I disable hyperthreading, who knows...
Can you give us a link where you saw those results?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mienai nous apporta ses lumieres en ce 2005-02-02 19:52:
> Alain <ele### [at] netscapenet> wrote:
>
>>I've seen benchmarks results that point to a possible preformance *improvement* by
disabling
>>hyperthreading.
>>
>>Alain
>
>
> I'm sure it's possible that there could be an improvement, but my results
> went the other way. Maybe My mobo doesn't properly set the CPU in the
> correct mode when I disable hyperthreading, who knows...
>
> Can you give us a link where you saw those results?
>
>
>
It can also be the result of different CPU build. The results That I mention where
with the early
hyperthreaded P4. The newer cores can have it implemented differently.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
