 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nicolas Alvarez" <nic### [at] gmail com> schreef in bericht
news:4bfda97c@news.povray.org...
> Getting 100% CPU usage is expected. But you shouldn't be getting any
> slowdown.
>
> Processes with low priority get all the CPU timeslices that aren't being
> used by a process with higher priority. As soon as an app in normal
> priority
> tries to use the CPU, POV-Ray will use less of it.
>
I understand that. My experience however is that, with the (low priority)
3.7 render active in the background, all other rapplications I start/use,
regularly /hang/ for some time (seconds to tens of seconds) before resuming
again. This is not the case with version 3.6, or at least hardly noticeable.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 09:19, schrieb Thomas de Groot:
>> Processes with low priority get all the CPU timeslices that aren't being
>> used by a process with higher priority. As soon as an app in normal
>> priority
>> tries to use the CPU, POV-Ray will use less of it.
>>
>
> I understand that. My experience however is that, with the (low priority)
> 3.7 render active in the background, all other rapplications I start/use,
> regularly /hang/ for some time (seconds to tens of seconds) before resuming
Same here.
I guess the Windows scheduler gives comparatively long time slices to
processes, and doesn't cut them short even if higher-priority processes
are ready. So while in /theory/ applications shouldn't bother about
scheduling, in /practice/ it would be good if POV-Ray yielded its time
slices now and again, at least on Windows systems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 28 May 2010 12:36:58 +0200, clipka <ano### [at] anonymousorg> wrote:
>
> I guess the Windows scheduler gives comparatively long time slices to
> processes, and doesn't cut them short even if higher-priority processes
> are ready.
That is not what they say:
http://msdn.microsoft.com/en-us/library/ms685100.aspx
"If a higher-priority thread becomes available to run, the system ceases
to execute the lower-priority thread (without allowing it to finish using
its time slice), and assigns a full time slice to the higher-priority
thread."
A quick test on my own system shows that the GUI of other applications can
get slightly sluggish during a render, but not if I disable the preview
display. Perhaps POV-Ray spends a noticeable amount of time drawing the
preview (GDI functions are notoriously slow) and Windows does not want to
preempt that (either because some parts are non-reentrant or because
drawing to the screen temporarily boosts priority; I do not know).
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 13:04, schrieb Fredrik Eriksson:
> On Fri, 28 May 2010 12:36:58 +0200, clipka <ano### [at] anonymousorg> wrote:
>>
>> I guess the Windows scheduler gives comparatively long time slices to
>> processes, and doesn't cut them short even if higher-priority
>> processes are ready.
>
> That is not what they say:
>
> http://msdn.microsoft.com/en-us/library/ms685100.aspx
>
> "If a higher-priority thread becomes available to run, the system ceases
> to execute the lower-priority thread (without allowing it to finish
> using its time slice), and assigns a full time slice to the
> higher-priority thread."
Then there must be some other reason for the effects I do see. Maybe
some effects due to priority boosts?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 28 May 2010 17:31:09 +0200, clipka <ano### [at] anonymousorg> wrote:
>
> Then there must be some other reason for the effects I do see.
What effects do you see? As I said before, for me any issues seem to only
be noticeable with the preview display active, so it might be something to
do with that.
> Maybe some effects due to priority boosts?
The conditions for priority boosts are described here:
http://msdn.microsoft.com/en-us/library/ms684828.aspx
The article also explains how to prevent priority boosts from happening.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 18:16, schrieb Fredrik Eriksson:
> On Fri, 28 May 2010 17:31:09 +0200, clipka <ano### [at] anonymousorg> wrote:
>>
>> Then there must be some other reason for the effects I do see.
>
> What effects do you see? As I said before, for me any issues seem to
> only be noticeable with the preview display active, so it might be
> something to do with that.
I virtually always have the preview display active, so yes - it might
indeed be related to that. Doesn't make it any better though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> I understand that. My experience however is that, with the (low priority)
> 3.7 render active in the background, all other rapplications I start/use,
> regularly /hang/ for some time (seconds to tens of seconds) before resuming
> again. This is not the case with version 3.6, or at least hardly noticeable.
did you try with 3.7 using only one thread? The difference
in behavior compared to 3.6 might simply be that 3.6 could not
really stress your dualcore CPU.
Also you might check if memory is running low if the
system starts feeling unresponsive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 19:44, schrieb clipka:
>> What effects do you see? As I said before, for me any issues seem to
>> only be noticeable with the preview display active, so it might be
>> something to do with that.
>
> I virtually always have the preview display active, so yes - it might
> indeed be related to that. Doesn't make it any better though.
Having kept an eye open, I noticed that responsivity is poor only at
certain intervals, and I also have the impression that these indeed
correlates with the finishing of SMP sub blocks.
So I think this calls for closer examination and - if possible -
elimination of this issue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <ano### [at] anonymousorg> schreef in bericht
news:4c02c2f7$1@news.povray.org...
> Having kept an eye open, I noticed that responsivity is poor only at
> certain intervals, and I also have the impression that these indeed
> correlates with the finishing of SMP sub blocks.
>
> So I think this calls for closer examination and - if possible -
> elimination of this issue.
Do you want me to issue a bug report?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that Christoph has - maybe - tracked down the problem. See his post
of yesterday, just above.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
