I tried an experiment rendering a rather simple scene (a few primitives on a
plane with one light) using sse2 b3.  My machine has a P4.3GHz processor
with HT.

Threads  Time  % improvement
-----------------------------
1        72.58      0
2        63.83     12
4        64.90     11
8        59.90     17
16       54.75     25
32       50.20     31
64       48.27     33
128      49.00     32
255      47.83     34

So it seems that for a simple scene I can get a 33% speed increase by using
64 or more threads (rather than 1 thread).  Is there any reason for this,
and due to memory transfer etc will it not be as noticeable for bigger
scenes?

BTW it's also pretty cool to watch the preview when using 255 threads :-)

Post a reply to this message

scott <sco### [at] spamcom> wrote:
> Threads  Time  % improvement
> -----------------------------
> 4        64.90     11

  That's odd. According to my tests using the default 4 threads gives
an increase in speed of approximately 20%. That 11% figure seems quite
low.
  Perhaps your scene was too specific or something?

-- 
                                                          - Warp

Post a reply to this message

There seems to indeed be a slight speedup when the number of threads
grows larger, even though I didn't get such a big speedup as you.
I tried rendering isocacti.pov (at 640x480 +a +am2) in my 3.4GHz P4:
With 4 threads it took 7m 33s, with 64 threads it took 7m 26s.
Not such a big speedup as yours, but something.

  My best guess is that this happens because of the way hyperthreading
works in the Pentium4.

  The Pentium4 emulates two cores, but in a limited way because it
really just has one core. The idea is that even though there is only
one core, this core is composed of several independent parts, namely
the ALU, the FPU and the SSE processing unit. The idea in hyperthreading
is that while one process uses one of those units, another process can
use another of those units at the same time, in parallel.
  The P4 emulates two cores and runs threads truely in parallel if they
are using different units in the core, but falls back to run the processes
in alternation if they are using the same unit.

  Since POV-Ray uses both integer math and floating point math, and also
some SSE math if you have the SSE optimized binary, running POV-Ray in
several threads will give a speed advantage because two threads will be
run truely in parallel if one of then is eg. making floating point
operations and the other is performing integer math.

  My guess is that when you increase the number of threads to a quite big
amount (like 64 or more), the chances of the CPU being able to run code
truely in parallel increase. The more threads, the more chances for
parallel execution of some of the routines.

-- 
                                                          - Warp

Post a reply to this message

By the way, I noticed that if you increase the number of threads
it takes longer for povray to stop rendering (when the stop button
is pressed). The more threads, the longer it takes.
  Is this normal and to be expected?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   By the way, I noticed that if you increase the number of threads
> it takes longer for povray to stop rendering (when the stop button
> is pressed). The more threads, the longer it takes.
>   Is this normal and to be expected?

We'll be making a change that hopefully will improve things there.

-- Chris

Post a reply to this message

Warp wrote:
>   By the way, I noticed that if you increase the number of threads
> it takes longer for povray to stop rendering (when the stop button
> is pressed). The more threads, the longer it takes.
>   Is this normal and to be expected?

Stopping cleanly isn't trivial in a multithreaded C++ program as there is no 
language support for threading.  It has to be done trowing an exception, 
which in turn requires a specific point to do so.  That point is a call the 
thread has to make every now and then.  It currently does it only once per 
pixel in every thread,and the more threads you start the longer it takes, 
especially when doing anti-aliasing.  We are going to look for a better 
place (probably a test for each ray) and hopefully this will improve 
response time.

	Thorsten

Post a reply to this message

> Stopping cleanly isn't trivial in a multithreaded C++ program as there is
no
> language support for threading.  It has to be done trowing an exception,
> which in turn requires a specific point to do so.  That point is a call
the
> thread has to make every now and then.  It currently does it only once per
> pixel in every thread,and the more threads you start the longer it takes,
> especially when doing anti-aliasing.  We are going to look for a better
> place (probably a test for each ray) and hopefully this will improve
> response time.


Might I suggest that during this time, the Stop button (and any equivalents
in the menus) be disabled? It would make it "feel" a lot more like POV-Ray
is trying to do what you say, since it's responding, at least in a small
way, to your click.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> Might I suggest that during this time, the Stop button (and any equivalents
> in the menus) be disabled? It would make it "feel" a lot more like POV-Ray
> is trying to do what you say, since it's responding, at least in a small
> way, to your click.

  Actually that's exactly what povray does.

  However, perhaps there could be some more visible message somewhere
saying something like "waiting for threads to finish".

-- 
                                                          - Warp

Post a reply to this message

Slime wrote:
> Might I suggest that during this time, the Stop button (and any equivalents
> in the menus) be disabled? It would make it "feel" a lot more like POV-Ray
> is trying to do what you say, since it's responding, at least in a small

I do this, however it's only in response to the backend acknowledgement of
the stop request. If I disabled it before then, and the backend didn't stop
(this can happen), you wouldn't be able to try again.

-- Chris

Post a reply to this message

> I do this, however it's only in response to the backend acknowledgement of
> the stop request. If I disabled it before then, and the backend didn't
stop
> (this can happen), you wouldn't be able to try again.

Oh. Generally this has only happened to me when a scene takes up a ton of
memory, and things are starting to thrash. This is when I start to click
Stop like crazy, until I eventually ctrl+alt+del the whole thing out of
frustration. =) (Not that that really speeds anything up.)

I like Warp's suggestion; maybe something in the status bar would be nice.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message