 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <nomail@nomail> wrote:
> "Fractracer" <lg.### [at] gmail com> wrote:
> > "Thorsten Froehlich" <nomail@nomail> wrote:
> > > "Fractracer" <lg.### [at] gmailcom> wrote:
> > > > I don't know if my question do go in this group. But...
> > > > Why rendering with medias are slower with pov3.7, more then two times longer
as
> > > > with pov3.6? I use rarely the 3.7 version.
> > >
> > > My crystal ball suggests that a black wizard inside your computer makes media
> > > slower for you.
> > >
> > > No serious: You make a generic claim without any additional information. How is
> > > anybody to offer any help with your problem if you do not even provide any means
> > > to replicate your specific problem?
> > >
> > > Thorsten
> >
> > Here the times for the same little scene:
> > V3.7
> > Render Time:
> > Photon Time: No photons
> > Radiosity Time: No radiosity
> > Trace Time: 0 hours 0 minutes 5 seconds (5.211 seconds)
> > using 2 thread(s) with 9.749 CPU-seconds total
> >
> >
> > V3.6
> > Total Scene Processing Times
> > Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
> > Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
> > Render Time: 0 hours 0 minutes 8 seconds (8 seconds)
> > Total Time: 0 hours 0 minutes 8 seconds (8 seconds)
> > CPU time used: kernel 1.15 seconds, user 7.02 seconds, total 8.17 seconds
> > Render averaged 37580.50 PPS over 307200 pixels
> >
> > In this simple scene you can see that the rendering is slower with v3.7 (9.749
> > vs 8.17). If I use a big scene the difference increase.
> > The scene file used is the same.
> > I hope you have enough informations to understand my problem.
>
> How do the times help to replicate your problem? Please be specific! You say you
> have some scene and you claim its media is slower, how did you determine media
> is the problem? Do all media scenes render slower? You need to provide a minimal
> sample scene, assuming you can actually replicate the problem and show that it
> is media related.
>
> Thorsten
I re-render the scene without medias and the trace time are also very different
(37 secondes with 3.6 and 99 sec with 3.7). Maybe medias are not in cause, but
objects with hollow. And the pictures are different in shining.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Todd Carnes <tod### [at] gmailcom> wrote:
> It doesn't really matter if trace time is shorter for 3.7, if the total
> time he has to wait is longer.
That doesn't make any sense. If the trace time is shorter, how can he be
waiting longer? That's contradictory.
With v3.6 he had to wait for 8 seconds for the image to be rendered,
while with v3.7 he had to wait for 5 seconds. It seems that you also
have a rather strange definition of time.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/03/2013 09:42 AM, Fractracer wrote:
> I re-render the scene without medias and the trace time are also very different
> (37 secondes with 3.6 and 99 sec with 3.7). Maybe medias are not in cause, but
> objects with hollow. And the pictures are different in shining.
>
I've not seen differences as extreme as what you are reporting above,
but I have seen increases more like your first numbers for CPU time
consumed.
With multi-core, mult-thread machines it is hard to determine actual
code performance unless you can keep thread counts < CPU core counts for
>>everything<< running significant cycles on your machine.
I took a look using the shipped scene hollow.pov to try something
similar but different to your scene on ubuntu 12.04 using the unix time
command. With the time command the user time is very close to povray
time reported. Also, below "povray" is 3.7 RC7.
time povray361 hollow2.pov +W1200 +H1200 +A -D
real 0m23.470s (Elapsed time)
user 0m23.401s (This plus sys ~= CPU time)
sys 0m0.004s
time povray hollow2.pov +W1200 +H1200 +A -D -WT1
real 0m21.775s
user 0m21.297s (1 thread 3.7 is actually faster than 3.61)
sys 0m0.044s
time povray hollow2.pov +W1200 +H1200 +A -D -WT8
real 0m5.632s
user 0m33.806s (8 threads, more like the CPU increase 1st reported)
sys 0m0.048s
------------------
If I remove hollow & interior from spheres, I get the following times
looking first at 3.61 then 3.7rc7 from 1 to 8 threads running on a 4
core, 8 thread i7 920:
time povray361 hollow2_A.pov +W1200 +H1200 +A -D
real 0m6.803s
user 0m6.780s
sys 0m0.000s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT1
real 0m8.596s
user 0m8.129s (1 thread here a little slower)
sys 0m0.052s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT2
real 0m4.985s
user 0m8.309s
sys 0m0.052s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT3
real 0m3.733s
user 0m8.281s
sys 0m0.064s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT4
real 0m3.087s
user 0m8.345s
sys 0m0.048s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT5
real 0m2.986s
user 0m9.773s (Once thread > core count, CPU jumps)
sys 0m0.060s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT6
real 0m2.937s
user 0m11.069s (jumps some more)
sys 0m0.048s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT7
real 0m2.890s
user 0m12.309s (and more)
sys 0m0.048s
time povray hollow2_A.pov +W1200 +H1200 +A -D -WT8
real 0m2.793s
user 0m13.241s (...)
sys 0m0.052s
-------------------
The % increase in total CPU consumed with 1 vs 8 threads is about the
same with and without hollow/interior/media for the spheres.
1 -> 8 threads with hollow/media +58.74%
1 -> 8 threads no hollow/media +62.89%
If I run instead an isosurface scene :
1 vs 4 threads -1.26% CPU consumed.
1 vs 8 threads +30.87% CPU consumed.
Despite CPU consumed increasing when threads > CPU cores, the 8 thread
cases provide the best elapsed time in 3.7.
There are many other factors in caches, compilers, memory bandwidth, CPU
architecture, code changes etc in addition to thread count relative to
core count, that can affect CPU time consumed. Expect one or more of
those issues is why the % increase in consumed CPU is different scene to
scene once threads > core count.
Sorry I got long winded. Mostly wanted to say if wondering about 3.6 to
3.7 relative performance, my recommendation would be to always use one
thread in 3.7 on a machine where you are sure the thread count < core
count for all active processes over the elapsed time povray is running.
If you have that, everything else that can be the same is, and you still
see a significant and repeatable performance difference - perhaps the
difference is meaningful (1).
Hope some help.
Bill P.
(1) - Yes, it is possible to have performance issues related to the SMP
of 3.7, but I'd bet them not that common. Even when present they should
show up using thread counts > 1 and <= the CPU core count on the
machine. In other words, it would still make sense to take the thread >
core CPU increase out of any comparison.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/3/2013 1:45 PM, Warp wrote:
> That doesn't make any sense. If the trace time is shorter, how can he be
> waiting longer? That's contradictory.
I do not have a strange definition of time. You are not including
everything. There is more to it than just the trace time.
It is not contradictory nor is it complicated to understand. It just
means something other than the trace is eating up time.
For example, it could be that the parser is taking a lot longer to
perform its job. In that case, if the trace takes, for example, 1 second
less time to perform, but the parser takes 10 seconds more time to
perform it's job, you have still added an extra 9 seconds to your
overall time... Simple. :)
The general user is not going to care how much you've improved the trace
time, if your overall time to finish the scene increases. As far as
they're concerned, the program is slower.
Todd
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/03/2013 04:26 PM, Todd Carnes wrote:
> It is not contradictory nor is it complicated to understand. It just
> means something other than the trace is eating up time.
>
> For example, it could be that the parser is taking a lot longer to
> perform its job. In that case, if the trace takes, for example, 1 second
> less time to perform, but the parser takes 10 seconds more time to
> perform it's job, you have still added an extra 9 seconds to your
> overall time... Simple. :)
I would almost expect the parser would naturally take longer the way
it's implemented (no slam intended) ... more keywords (more tests) and
all the backward compatibility that's being maintained. Not saying that
this is what the OP is seeing, but I /would/ say that the parser is
indeed a bit fat and could use a diet ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/3/2013 5:06 PM, James Holsenback wrote:
> On 07/03/2013 04:26 PM, Todd Carnes wrote:
>> It is not contradictory nor is it complicated to understand. It just
>> means something other than the trace is eating up time.
>>
>> For example, it could be that the parser is taking a lot longer to
>> perform its job. In that case, if the trace takes, for example, 1 second
>> less time to perform, but the parser takes 10 seconds more time to
>> perform it's job, you have still added an extra 9 seconds to your
>> overall time... Simple. :)
>
> I would almost expect the parser would naturally take longer the way
> it's implemented (no slam intended) ... more keywords (more tests) and
> all the backward compatibility that's being maintained. Not saying that
> this is what the OP is seeing, but I /would/ say that the parser is
> indeed a bit fat and could use a diet ;-)
>
I do not envy the guys who are maintaining povray. It must be terribly
difficult to maintain backward compatibility and yet still add nifty new
features like SMP. I think they've done a great job. :)
Todd
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Todd Carnes <tod### [at] gmailcom> wrote:
> The general user is not going to care how much you've improved the trace
> time, if your overall time to finish the scene increases. As far as
> they're concerned, the program is slower.
There's some kind of misunderstanding here.
With POV-Ray 3.6 it took 8 seconds to get the final image.
With POV-Ray 3.7 it took 5 seconds to get the final image.
Where exactly is this "the user has to wait longer" you are seeing?
Because I'm not seeing it. The user had to way 3 seconds longer with
POV-Ray 3.6 in order to get the image than with POV-Ray 3.7.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<snip>
> I re-render the scene without medias and the trace time are also very different
> (37 secondes with 3.6 and 99 sec with 3.7). Maybe medias are not in cause, but
> objects with hollow. And the pictures are different in shining.
>
>
>
"hollow" can't cause any difference in the render time. It's sole
purpose it to enable an object to contain some media. If you remove the
media, then, hollow does absolutely nothing.
Looking back at your sample scene, ALL your light will emit photons if
you turn photons ON in the global_settings.
The photons block for a light_source is usefull to turn feature OFF and
to enable area_light. refraction and reflection default to ON.
assumed_gamma 1.2 should generate a warning and be reset to 1. Beter to
set it a 1.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/4/2013 11:48 AM, Warp wrote:
> Todd Carnes <tod### [at] gmailcom> wrote:
>> The general user is not going to care how much you've improved the trace
>> time, if your overall time to finish the scene increases. As far as
>> they're concerned, the program is slower.
>
> There's some kind of misunderstanding here.
>
> With POV-Ray 3.6 it took 8 seconds to get the final image.
>
> With POV-Ray 3.7 it took 5 seconds to get the final image.
>
> Where exactly is this "the user has to wait longer" you are seeing?
> Because I'm not seeing it. The user had to way 3 seconds longer with
> POV-Ray 3.6 in order to get the image than with POV-Ray 3.7.
>
No, just as the OP posted more than once...
POV-Ray 3.6 took 8.17 seconds to get to the final image.
POV-Ray 3.7 took 9.749 seconds to get to the final image.
I don't understand why you can't read these numbers for yourself. I will
copy them from the OP's post repost them again below.
For the record, I'm finding this whole "discussion" about a render that
only has a second or two difference to be pretty pointless. Whether you
choose open your eyes and actually read what was posted or not, I am
going to drop this pointless conversation.
Anyway, AGAIN, the OP's original numbers...
Fractracer <lg.### [at] gmailcom> wrote:
> Here the times for the same little scene:
> V3.7
> Render Time:
> Photon Time: No photons
> Radiosity Time: No radiosity
> Trace Time: 0 hours 0 minutes 5 seconds (5.211 seconds)
> using 2 thread(s) with 9.749 CPU-seconds total
> V3.6
> Total Scene Processing Times
> Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
> Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
> Render Time: 0 hours 0 minutes 8 seconds (8 seconds)
> Total Time: 0 hours 0 minutes 8 seconds (8 seconds)
> CPU time used: kernel 1.15 seconds, user 7.02 seconds, total 8.17 seconds
> Render averaged 37580.50 PPS over 307200 pixels
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 04/07/2013 22:36, Todd Carnes nous fit lire :
> On 7/4/2013 11:48 AM, Warp wrote:
>> Todd Carnes <tod### [at] gmailcom> wrote:
>>> The general user is not going to care how much you've improved the trace
>>> time, if your overall time to finish the scene increases. As far as
>>> they're concerned, the program is slower.
>
> POV-Ray 3.6 took 8.17 seconds to get to the final image.
> POV-Ray 3.7 took 9.749 seconds to get to the final image.
>
> I don't understand why you can't read these numbers for yourself. I will
> copy them from the OP's post repost them again below.
CPU usage is increased. (from 8s to 9.749s)
Wall clock is less. (from 8s to 5.211s)
Stop misinterpreting the output.
Yes, version 3.7RC7 might be slower (at least on some aspects), but it
is able to handle multicore CPU, a thing that 3.6 did not.
> Anyway, AGAIN, the OP's original numbers...
>
> Fractracer <lg.### [at] gmailcom> wrote:
>> Here the times for the same little scene:
>> V3.7
>> Render Time:
>> Photon Time: No photons
>> Radiosity Time: No radiosity
>> Trace Time: 0 hours 0 minutes 5 seconds (5.211 seconds)
>> using 2 thread(s) with 9.749 CPU-seconds total
>> V3.6
>> Total Scene Processing Times
>> Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
>> Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
>> Render Time: 0 hours 0 minutes 8 seconds (8 seconds)
>> Total Time: 0 hours 0 minutes 8 seconds (8 seconds)
>> CPU time used: kernel 1.15 seconds, user 7.02 seconds, total 8.17 seconds
>> Render averaged 37580.50 PPS over 307200 pixels
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
