|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 24 Jul 2008 17:21:35 +0200, scott wrote:
>>> Of course there is, if a certain amount of code needs to be executed
>>> by the CPU to "launch" the program, I want my OS to use 100% CPU until
>>> it's done. Whether that takes 0.01ms or 1 second, it should still use
>>> 100% CPU until it's done. What on Earth is the reason not to?
>>
>> If that program takes 100% of the CPU, then *nothing* else gets any CPU
>> - other applications, the OS, etc. Those things need resources, too.
>
> I meant the CPU being at 100% during the program loading, not that
> particular program using 100% all for itself. Of course I assume the OS
> can do important things, but still the CPU should not be below 100%
> while I am waiting for a program to load (assuming it's CPU bound).
> That would be just wasted time.
Generally that isn't going to happen on modern processors, though,
because the CPU hits 100% during computationally intensive periods, but
internal clock speeds on CPUs these days tend to be *several times* the
speed of even the bus to the CPU.
One of the reasons Intel entered the networking components market was
because CPU utilization on their faster generations of processors was
relatively low because of the speed differential between the time it took
to process data and the time it took to get the data (or code, rather) to
the processor to actually process things.
That may be what you're talking about here. But this is why you won't
see a CPU hit 100% during program load - the bus just isn't fast enough
relative to the speed of the CPU. Therefore, if you want to see 100%
load on the CPU during a program load, you need a slower processor (until
bus speeds catch up with CPU speeds, and that won't happen because of the
physical distance the data has to travel on the bus to get to the CPU,
where everything is nm apart instead of inches apart.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> I meant the CPU being at 100% during the program loading, not that
> particular program using 100% all for itself. Of course I assume the OS can
> do important things, but still the CPU should not be below 100% while I am
> waiting for a program to load (assuming it's CPU bound). That would be just
> wasted time.
Often when a program loads, it reads a lot of data from the disk. This
means that most programs are I/O-intensive during loading, not CPU-intensive.
(Basically the CPU has to constantly wait for the superslow hard disk to do
its job.)
Some programs might perform some other forms of I/O during loading,
which may also cause the CPU to have to wait mostly idle. For example
a game could be loading tons of textures to the GPU memory, which takes
its time.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> On Thu, 24 Jul 2008 11:20:54 -0400, Warp wrote:
> > That's not how pre-emptive multitasking works.
> Yes, I am aware of how pre-emptive vs. non-preemptive multitasking
> works.
In fact, even in a cooperative multitasking system a process taking
100% of CPU time doesn't necessarily mean the system is locked into
that single process. The process may still be nicely sharing time, but
if it's the only CPU-intensive process running, it may be getting all
of the available CPU time.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 24 Jul 2008 11:45:16 -0400, Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Thu, 24 Jul 2008 11:20:54 -0400, Warp wrote:
>
>> > That's not how pre-emptive multitasking works.
>
>> Yes, I am aware of how pre-emptive vs. non-preemptive multitasking
>> works.
>
> In fact, even in a cooperative multitasking system a process taking
> 100% of CPU time doesn't necessarily mean the system is locked into that
> single process. The process may still be nicely sharing time, but if
> it's the only CPU-intensive process running, it may be getting all of
> the available CPU time.
Yep, absolutely - utilization figures are typically trended, and there
usually is more than one process in the "task queue", even when something
tries to take over the system entirely. Interrupts and whatnot being in
place means there's always something else that can take control unless
the program has the ability (at the kernel level) to truly take
everything over.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Generally that isn't going to happen on modern processors, though,
> because the CPU hits 100% during computationally intensive periods,
Yeh that's what I meant, like if the CPU had to decompress some files during
loading (eg game graphics or whatever), assuming it is CPU-bound then of
course I want the CPU usage to be at 100%.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 25 Jul 2008 09:02:08 +0200, scott wrote:
>> Generally that isn't going to happen on modern processors, though,
>> because the CPU hits 100% during computationally intensive periods,
>
> Yeh that's what I meant, like if the CPU had to decompress some files
> during loading (eg game graphics or whatever), assuming it is CPU-bound
> then of course I want the CPU usage to be at 100%.
That's a big assumption, though, and not generally the way things work.
And even then, you're assuming that the speed of the CPU core = the speed
of the bus to the memory, and that just isn't happening on modern systems
any more.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|