 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Todd Carnes <tod### [at] gmail com> wrote:
>> 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.
>>
>> When I post my first question, I have worked on another scene and the time for
> rendering was strongly increase with v3.7 (in this case the difference was more
> than one or two seconds). The scene I have posted here is just an example test.
>
>
>
The final word is that, with version 3.7, you get TWO times while
version 3.6 only have one:
Time 1 is external, wall clock, time. It's the time you actualy have to
wait.
Time 2 is internal, total CPU time. It's the SUM of the time taken by
ALL cores or CPUs of your computer. This time can get significatively
larger than the strictly single thread process of version 3.6.x while
the external, wall clock time, get shorter.
Next, with some scenes, the IO processes can bog you down. This tend to
affect mostly very complexe scenes or hit you when rendering at very
large dimentions, like 32000 by 24000 or more...
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
You are interpreting the numbers incorrectly, you are even more wrong
when you have lots of CPU cores, as in this example:
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 3 seconds (3.266 seconds)
using 12 thread(s) with 36.795 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 0.09 seconds, user 36.97 seconds, total 37.07 seconds.
Elapsed time 3.97 seconds, CPU vs elapsed time ratio 9.33.
Render averaged 58020.65 PPS (6215.97 PPS CPU time) over 230400 pixels.
That scene was done in 3.97 seconds, not 37.07 seconds!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/04/2013 10:36 PM, Alain wrote:
>
> The final word is that, with version 3.7, you get TWO times while
> version 3.6 only have one:
>
> Time 1 is external, wall clock, time. It's the time you actualy have to
> wait.
>
> Time 2 is internal, total CPU time. It's the SUM of the time taken by
> ALL cores or CPUs of your computer. This time can get significatively
> larger than the strictly single thread process of version 3.6.x while
> the external, wall clock time, get shorter.
>
> Next, with some scenes, the IO processes can bog you down. This tend to
> affect mostly very complexe scenes or hit you when rendering at very
> large dimentions, like 32000 by 24000 or more...
>
>
>
> Alain
I have not tested, nor will I, all the claims that have been made here,
but one thing that I have noticed is that povray 3.7 takes longer to
store an image once it's done rendering it. I assume it's because of the
pov-state file which, in my case, is stored on a server.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/04/2013 11:36 PM, Alain wrote:
>> Todd Carnes <tod### [at] gmailcom> wrote:
>>> 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.
>>>
>>> When I post my first question, I have worked on another scene and the
>>> time for
>> rendering was strongly increase with v3.7 (in this case the
>> difference was more
>> than one or two seconds). The scene I have posted here is just an
>> example test.
>>
>>
>>
>
> The final word is that, with version 3.7, you get TWO times while
> version 3.6 only have one:
>
> Time 1 is external, wall clock, time. It's the time you actualy have to
> wait.
>
> Time 2 is internal, total CPU time. It's the SUM of the time taken by
> ALL cores or CPUs of your computer. This time can get significatively
> larger than the strictly single thread process of version 3.6.x while
> the external, wall clock time, get shorter.
>
> Next, with some scenes, the IO processes can bog you down. This tend to
> affect mostly very complexe scenes or hit you when rendering at very
> large dimentions, like 32000 by 24000 or more...
>
>
>
> Alain
Yep ... well said. I'd like to also add that more file I/O can occur
with larger images if:
http://wiki.povray.org/content/Reference:General_Output_Options#Max_Image_Buffer_Memory
has been exceeded
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/05/2013 03:28 AM, Ger Remmers wrote:
> On 07/04/2013 10:36 PM, Alain wrote:
> I have not tested, nor will I, all the claims that have been made here,
LOL ... agreed
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Todd Carnes <tod### [at] gmailcom> wrote:
> 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.
As others have pointed out, you are confusing numbers here. 5 seconds
is what the render took in total. 9.7 seconds is sum of all the CPU
clock cycles that were spent in the rendering. But because they were
rendering in parallel, the total wallclock time was just 5 seconds.
With your interpretation, the more cores you use, the slower the
rendering. Therefore it would be the fastest to use just one core.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 07/04/2013 10:36 PM, Alain wrote:
>
>>
>> The final word is that, with version 3.7, you get TWO times while
>> version 3.6 only have one:
>>
>> Time 1 is external, wall clock, time. It's the time you actualy have to
>> wait.
>>
>> Time 2 is internal, total CPU time. It's the SUM of the time taken by
>> ALL cores or CPUs of your computer. This time can get significatively
>> larger than the strictly single thread process of version 3.6.x while
>> the external, wall clock time, get shorter.
>>
>> Next, with some scenes, the IO processes can bog you down. This tend to
>> affect mostly very complexe scenes or hit you when rendering at very
>> large dimentions, like 32000 by 24000 or more...
>>
>>
>>
>> Alain
>
> I have not tested, nor will I, all the claims that have been made here,
> but one thing that I have noticed is that povray 3.7 takes longer to
> store an image once it's done rendering it. I assume it's because of the
> pov-state file which, in my case, is stored on a server.
>
The image file is not created untill the trace is finished. All the
image information is keept in the .povstate file and in a RAM buffer.
When using version 3.6 and older, the image is updated at the end of
each rendered line. That way, you are not aware of that time as it's
spread throuhough the tracing process.
There is a side effect when creating a PNG image. With version 3.7, the
image file is possibly slightly smaller. Encoding the whole image can
result in a more effecient compression than when encoding it one line at
a time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.07.2013 23:06, schrieb James Holsenback:
> I /would/ say that the parser is
> indeed a bit fat and could use a diet ;-)
No way. We're going to slaughter it, eat it, and breed a new one :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.07.2013 09:28, schrieb Ger Remmers:
> I have not tested, nor will I, all the claims that have been made here,
> but one thing that I have noticed is that povray 3.7 takes longer to
> store an image once it's done rendering it. I assume it's because of the
> pov-state file which, in my case, is stored on a server.
It might actually be the time POV-Ray needs to clean up the pov-state
file. It can be pretty bad on Windows systems.
Again on Windows systems, there's also a known problem when the image is
too simple: The thread responsible for assembling the image from the
rendered chunks may become swamped with finished chunks, and may still
be busy processing them all long after the render threads have already
done their job. With large images, this can even lead to the paradox
situation that the simpler the scene gets the more physical memory is
eaten up during the render. (Fortunately, if this maxes out physical
memory it only bogs down the POV-Ray thread, and doesn't throw the
entire system into swap hell like it would happen in other situations.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Again on Windows systems, there's also a known problem when the image is
> too simple: The thread responsible for assembling the image from the
> rendered chunks may become swamped with finished chunks, and may still
> be busy processing them all long after the render threads have already
> done their job. With large images, this can even lead to the paradox
> situation that the simpler the scene gets the more physical memory is
> eaten up during the render. (Fortunately, if this maxes out physical
> memory it only bogs down the POV-Ray thread, and doesn't throw the
> entire system into swap hell like it would happen in other situations.)
On my last system (1GB RAM, 1 core, 4 threads), I ended up in swap hell quite a
lot in Linux, but not in Windows. The entire system was near frozen, not just
POV-Ray. The scenes were conceptually simple, but had lots of media containers
overlapping in line-of-sight, so I don't think it was a case of blocks rendering
too fast. Typically, the render would proceed nicely, with RAM usage in linear
proportion to the progress of the render. (I eventually learned to shut down my
Web browser before rendering large images.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
