"Chambers" <ben### [at] pacificwebguycom> wrote in message 
news:3E8BA04547084C94A0AF378EADFB4C29@HomePC...
> Using Beta 30 x64, I got 70 seconds with one thread and 34 with two.
>
> Using the sse2 version of the modified executable, I got 72 seconds with
> one thread and 76 seconds with two!
>
> Something is definitely going on here... I'll be playing with the scene
> file...


That's a very short render time. Are you using the last  //cmd: +w1600 
+h1200  ini line? In any case, two similar render times with the SSE2 makes 
my computer seem to be at fault. The SSE2 is almost always what I use. So if 
you don't see a 5X or more slowing like I do here using 2 threads that's got 
to be something, right? Hope it leads to answers anyway (in POV not my 
file).

Sorry about the missing include file. That holiday symbols include is in my 
include subfolder, not in the place I have all these graph files. I never 
could create enough holiday symbols at such a tiny size to look good on the 
graph so it never became an important part. You might find most of it 
commented out to prevent non-current months from showing a holiday.
I've put it into a new file at 
http://0mniverse.com/public/37threads2slow.zip  which still needs 
clockmod.inc to run completely as-is.

I added the clock stuff to the animation //cmd:  line before uploading the 
file and neglected to put with it was  +kc  for looping the animation. I 
normally use what I have in my quickres.ini but thought it easier to just 
put these there in the scene file.
I've been able to clean up the SDL some, thanks to your asking to try it, 
but it remains awful. It lacks any commenting to explain most things, too, 
such as how's and why's of positioning objects.

Bob

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> wrote in message 
news:20CECB82D05043A6B6A700156C442C4B@HomePC...
>I don't have more time to work with it today, but I can definitely say
> that the effect seen is related to the overlapping graphs and the
> background.  Eliminating sets of data or the background both have the
> effect of reducing the effect.


Thanks Ben, just posted a reply before seeing this, uploaded a new file 
including the missing inc and I will try checking into that more.
I think I eliminated the orthographic camera, sor (raindrops), sphere_sweep, 
blob (thermometers) as being the trouble.

Haven't removed the background waves yet, but it's  function 
{(sin(cos(x/2)+(y/2))*z/2)*z}  color_map and not sure why that and 
overlapping (and layered textures) of the yearly columns would affect thread 
count... or why anything would. But like I said before I don't understand 
the inner workings of threading.

Bob

Post a reply to this message

> -----Original Message-----
> From: Bob Hughes [mailto:omniverse charter net]
> That's a very short render time. Are you using the last  //cmd: +w1600
> +h1200  ini line?

No, I was doing a custom render of -w800 -h600.  I'm not interested in
exact render times anyway, just the ratio of the render times.

Sorry I've been busy, I'm taking another look at the new file now.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

This new file renders at 800x600 in 35 seconds using one thread, and 19
seconds using two (800x600, no AA).

So the change has to do with what you removed between the two.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Disregard that, I was using the unmodified beta 30.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

OK, using the modified beta 30, render times for 800x600 w/ no AA are:

2 Threads: 79 seconds
1 Thread: 33 seconds.

The top 50% of the render completes in 17 seconds using either 1 or 2
threads, so something is odd there, but most of the problem is in the
lower half.

...

OK, some further testing revealed the main problem.

In the file lsl_legends-symbols.inc, try commenting out the code
beginning with:
text {
	ttf "arialbd.ttf",
	"NOMINAL",

And ending with:

#end  // SKIP PREVIOUS YEAR IF MONTH GRAPH
object {
	MinimalCurve
	translate <0,-6*52,-15>
}
translate 0.5*z
}


This makes the file render in 9 seconds with one thread, and 6 seconds
with two - which I would call a return to normalcy :)

Now, the next task is to come up with a simpler demonstration of the
problem.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> wrote in message 
news:E70AB5682EB0400CB22624BA6FD0F183@HomePC...
> OK, using the modified beta 30, render times for 800x600 w/ no AA are:
>
> 2 Threads: 79 seconds
> 1 Thread: 33 seconds.
>
> The top 50% of the render completes in 17 seconds using either 1 or 2
> threads, so something is odd there, but most of the problem is in the
> lower half.

That's much the same I get here, noticeably slower after about 45%.

> In the file lsl_legends-symbols.inc, try commenting out the code
> beginning with:
> text {
> ttf "arialbd.ttf",
> "NOMINAL",
>
> And ending with:
>
> #end  // SKIP PREVIOUS YEAR IF MONTH GRAPH
> object {
> MinimalCurve
> translate <0,-6*52,-15>
> }
> translate 0.5*z
> }
>
> This makes the file render in 9 seconds with one thread, and 6 seconds
> with two - which I would call a return to normalcy :)

Yep, that's the sphere_sweep part for those of you reading here. You deserve 
thanks for going through that mess of SDL!
I had taken one year of sphere sweeps out where the render gets very slow 
and it didn't seem to help as much as I would have thought it could so I 
left it alone from then on.

> Now, the next task is to come up with a simpler demonstration of the
> problem.

I went back to trying just certain parts in a new test file using the same 
stuff from the original, added in first one year then another, and got these 
render times.

Only sphere sweeps:

no AA 1 thread 19 sec
no AA 2 threads 11 sec
AA 1 thread 52 sec
AA 2 threads 29 sec

plus background:

no AA 1 thread 21 sec
no AA 2 threads 12 sec

plus year 2007 (in second half of image):

no AA 1 thread 47 sec
no AA 2 threads 33 sec

plus years 2004 (first half of image) and 2007:

no AA 1 thread 50 sec
no AA 2 threads 66 sec

And as you can see, this last one is where it turns times around.

I was checking whether or not layered texture cylinders overlapped in a 
similar way (in a new test file) would cause the slowdown by itself and only 
proved it wasn't the reason.

I keep thinking it must be something about the combination of sphere_sweep 
and the overlapping cylinders. My guess would be the bounding going crazy, 
which I could be wrong about. I just never expected anything like this to 
relate to number of threads. I can only presume this kind of thing will 
happen to other scene files.

Another test file I tried earlier was a sphere_sweep with random 3D points, 
looking like a tangled loose ball of string, with hundreds of objects used 
from the graph file and it failed to cause a reversal of render times due to 
thread count. In fact, I wasn't getting a significant slowdown. It could be 
my graph file is unique in regards to this thread count trouble but there 
has to be something peculiar about it. I got a 28X slower render once while 
checking it, from 10 sec to 280 sec. going from Work_Threads=1 to 2.

Thanks again for checking on it yourself, Ben.

Bob

Post a reply to this message

I just noticed the following comment in povray.cpp, function povray_init():

    // we can't use boost::thread::yield here since under windows it is not
    // guaranteed to give up a time slice [see API docs for Sleep(0)]
    // TODO - Maybe boost::thread under Windows needs a patch! [trf]
    while(POV_RenderContext == NULL)
    {
        boost::thread::yield();
        pov_base::Delay(50);
    }

This pattern of calling both boost::thread::yield() together with
pov_base::Delay() is used throughout POV-Ray, except for the functions
MainThreadFunction() in povray.cpp and vfeSession::WorkerThread() in
vfesession.cpp, which makes me wonder whether this is intended.

Post a reply to this message