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