 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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...
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
From: Bob Hughes
Subject: Re: thread count rendertimes unpredictable?
Date: 21 Jan 2009 23:52:32
Message: <4977fb90@news.povray.org>
|
|
|
| |
| |
|
|
"Chambers" <ben### [at] pacificwebguy com> 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
|
|
| |
| |
|
|
|
|
| |
