 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My PC has a quad-core CPU with hyperthreading. Which means that Windows
claims it has 8 cores, and when I run POV-Ray, it claims to be using
12.5% CPU.
Right now, I have 4 copies of POV-Ray running, each working on a
different task. Each copy is using 12.5% CPU, and Windows reports a
total of 50% CPU usage. (In spite of the fact that I'm actually using
ALL the cores available.)
I wanted to get a quick preview of the animation being built, so I fired
up Virtual Dub. Imagine my surprise when I actually got 62.5% CPU! o_O
Somehow, each core is running a compute-bound task, and yet still had
enough spare cycles to run a /second/ compute-bound task in the
background as well!
(Also slightly unusual is seeing Virtual Dub actually compute-bound.
Usually it's I/O-bound. But in this case - decoding PNG and encoding
H.264 at 1280x720 - it seems to have become compute-bound.)
The only explanation I can come up with is that POV-Ray is using almost
exclusively floating-point arithmetic, while Virtual Dub is using almost
exclusively integer arithmetic. (Can you *do* a discrete cosine
transform in integer arithmetic alone? I didn't though you could...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> I wanted to get a quick preview of the animation being built, so I fired
> up Virtual Dub. Imagine my surprise when I actually got 62.5% CPU! o_O
> Somehow, each core is running a compute-bound task, and yet still had
> enough spare cycles to run a /second/ compute-bound task in the
> background as well!
I don't understand what's so strange about that. The OS is sharing CPU time
among the processes. That's completely normal. In fact, it would be quite
abnormal if it *didn't* do that.
If you have, let's say for example, a 1-megabit internet connection and
start a big download, you may get (in an optimal situation) a download
speed of about 100 kilobytes/s.
If you now start another big download, you'll notice how the first one drops
to about 50 kilobytes/s and the second one gets a similar speed.
That's not strange, and shouldn't be. Why is sharing CPU time any stranger?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/07/2012 07:38 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> I wanted to get a quick preview of the animation being built, so I fired
>> up Virtual Dub. Imagine my surprise when I actually got 62.5% CPU! o_O
>> Somehow, each core is running a compute-bound task, and yet still had
>> enough spare cycles to run a /second/ compute-bound task in the
>> background as well!
>
> I don't understand what's so strange about that. The OS is sharing CPU time
> among the processes. That's completely normal. In fact, it would be quite
> abnormal if it *didn't* do that.
>
> If you have, let's say for example, a 1-megabit internet connection and
> start a big download, you may get (in an optimal situation) a download
> speed of about 100 kilobytes/s.
>
> If you now start another big download, you'll notice how the first one drops
> to about 50 kilobytes/s and the second one gets a similar speed.
>
> That's not strange, and shouldn't be. Why is sharing CPU time any stranger?
If you can get 100 kb/s, and you start a second download, the second
download goes at 50 kb/s, and the first one also slows down to 50 kb/s.
This is not strange.
Now imagine you get 100 kb/s, and you start a second download, and this
/also/ gets 100 kb/s, so your total download rate is now 200 kb/s. THAT
is strange.
This is what I saw happen. 4 tasks, each using 12.5% CPU. I added a 5th
task, and the existing 4 tasks stayed at 12.5%, and the 5th task also
got 12.5%. Even though that's 5 tasks on only 4 cores. Amazing!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> If you can get 100 kb/s, and you start a second download, the second
> download goes at 50 kb/s, and the first one also slows down to 50 kb/s.
> This is not strange.
> Now imagine you get 100 kb/s, and you start a second download, and this
> /also/ gets 100 kb/s, so your total download rate is now 200 kb/s. THAT
> is strange.
You are confusing usage percentage with speed. Windows doesn't tell you how
fast the processes are running (compared to maximum theoretical speed), only
how many (virtual) cores are currently being used (and at which ratio, if
not fully utilized.)
When Windows tells you that 50% of CPU time is in use, that doesn't mean
that the process is running at 50% of the maximum possible speed. In the
case of hyperthreading that's probably closer to 90% or something.
What the number is telling is how many virtual cores are being used at
the moment by that process (assuming that it's using all of the virtual
cores fully).
50% means that it's using half of all the virtual cores. 100% would mean
that it's using all of them. However, the latter doesn't necessarily mean
that the process is now running twice as fast. (With multithreading it
probably means a 10-30% speed increase, depending a lot on the type of
application.)
(Of course this with the caveat that, as said, the process is using the
core fully. If it's using it only partially, then then the system will
calculate how many %'s of the total available time on that virtual core
is being used by the process, and summing up the values from different
cores where the process is running.
Thus if you have for example 4 virtual cores and the process is using 50%
of two of them, then the total CPU time usage will be 25%, ie. the same as
if only one virtual core were fully utilized.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/07/2012 08:25 PM, Warp wrote:
> What the number is telling is how many virtual cores are being used at
> the moment by that process (assuming that it's using all of the virtual
> cores fully).
Ah, I see. The number measures the amount of processor time /allocated/
by the OS, not the amount of actual computation process made. Got it.
So if a task spends most of its time idle due to cache misses or sharing
executing units with a second hyperthreaded task, or whatever, the OS
can't easily measure that.
I guess the thing to do then is to look at the actual throughput
achieved by all the tasks. Both POV-Ray and Virtual Dub report this
information. (POV-Ray reports pixels/second, Virtual Dub reports
frames/second transcoded.)
Incidentally, does anybody /else/ find POV-Ray's PPS display annoying?
It seems to display the arithmetic mean over the entire image, which is
just /wrong/.
1. It means that if the speed increases or decreases for any reason, the
display takes a /long/ time to respond. I'd prefer to see an
instantaneous speed readout.
2. It includes any mosaic preview or radiosity pretrace rendering, which
has completely different speed characteristics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 09:59, schrieb Invisible:
> Incidentally, does anybody /else/ find POV-Ray's PPS display annoying?
> It seems to display the arithmetic mean over the entire image, which is
> just /wrong/.
No, it isn't.
The figure is the ratio between the count of some discrete events and
the time interval over which they are counted, specified in a fixed unit
of pixels per second (or, for lower values, pixels per minute).
Obviously, as we're talking about discrete events, you can't measure
this ratio for a particular /moment/, so you need to measure it over
/some/ timespan. It is up to the experimenter to choose one, and "the
duration of the whole experiment" is a perfectly valid one,
scientifically speaking.
You might consider the information /useless/, but that's something
totally different than being /wrong/.
> 1. It means that if the speed increases or decreases for any reason, the
> display takes a /long/ time to respond. I'd prefer to see an
> instantaneous speed readout.
OTOH it probably gives you a better overview of the render performance
for the scene as a whole.
> 2. It includes any mosaic preview or radiosity pretrace rendering, which
> has completely different speed characteristics.
Yes, but they're part of the effective rendering time.
Bottom line: You do have some point, but it's not nearly as strong as
you claim it to be.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.07.2012 20:22, schrieb Orchid Win7 v1:
> My PC has a quad-core CPU with hyperthreading. Which means that Windows
> claims it has 8 cores, and when I run POV-Ray, it claims to be using
> 12.5% CPU.
>
> Right now, I have 4 copies of POV-Ray running, each working on a
> different task. Each copy is using 12.5% CPU, and Windows reports a
> total of 50% CPU usage. (In spite of the fact that I'm actually using
> ALL the cores available.)
You're doing something fundamentally wrong here: You should have a
single instance of POV-Ray running, with 100% CPU utilization :-P
(Hint: Get POV-Ray 3.7!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 11:17 AM, clipka wrote:
> You're doing something fundamentally wrong here: You should have a
> single instance of POV-Ray running, with 100% CPU utilization :-P
>
> (Hint: Get POV-Ray 3.7!)
Maybe when the beta finishes, eh?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 11:05 AM, clipka wrote:
> Obviously, as we're talking about discrete events, you can't measure
> this ratio for a particular /moment/, so you need to measure it over
> /some/ timespan.
Sure. But a shorter timespan would be much more useful.
>> 1. It means that if the speed increases or decreases for any reason, the
>> display takes a /long/ time to respond. I'd prefer to see an
>> instantaneous speed readout.
>
> OTOH it probably gives you a better overview of the render performance
> for the scene as a whole.
It might be useful if POV-Ray could actually try to estimate the time
remaining. It's not especially useful looking at the average PPS for the
entire scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> > 1. It means that if the speed increases or decreases for any reason, the
> > display takes a /long/ time to respond. I'd prefer to see an
> > instantaneous speed readout.
> OTOH it probably gives you a better overview of the render performance
> for the scene as a whole.
Maybe it should display two numbers: "Overall PPS" and "Current PPS".
The latter one would be the average of the last n pixels (where n would
be something small, such as 10).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
