[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Re: 100% CPU
On 4/23/07, Dave LeCompte (really) <dave@xxxxxxxxxxxx> wrote:
Brian Fisher told me that a CPU is not a saw:
> However it is also nowhere near an applicable analogy in this case. So
> if you only ever used 20% of the cpu, I guess you'll burn out that 20%
> and then have to throw away an 80% good cpu? What a waste. All those
> 80% good intel CPU's lounging in a trash heap!
Ok, so I'm not burning out 20% of the pins on the CPU, or wearing down 20%
of the transistors to nubs, but I still believe it's valid. If I have a
2GHz CPU, and I only use 20% of it over its entire lifetime, didn't I
really waste 80% of my CPU? I could have saved some cash and bought myself
a 500MHz CPU, and got the same number of calculations out of it, right?
Not unless your time that you spend on the computer is worthless.
Also, don't forget that the CPU is not the only major component in
your computer that affects speed.
You mention that it's a good idea to set aside 1% of the CPU to be used by
the OS, and that's probably a very good rule of thumb - by all means, let
the high priority apps hit the CPU to do what they need to do, but the
remainder of the processing power of the machine is ripe to be used.
No one's saying you shouldn't "use" them. We're trying to beat it
into your head that the magic ideal is not "using 100% CPU" for most
applications.
That's a cool image. But if the available cycles aren't lost, how would
you describe them? I can't go back and use them now, so how is that
different from my malicious bank account metaphor?
I think you're generating more responses from your bad metaphors than
anything else. How about you explain how CPU cycles are LIKE your
malicious bank account example?
Oh, and perhaps someone's thinking that I'm advocating doing a busy wait
during idle times - certainly not. A busy wait (spinning the CPU, checking
some exit case), when a sleep or other well-implemented blocking call is
available, is a waste of CPU.
Ah, well, then you might want to stop putting forth arguments that the
CPU be used without qualifying what it be used for. I'd venture a
guess that there are only a handful (if that many) of pygame projects
that make use of infinite precision physics or
calculate-as-many-chess-moves-as-I-possibly-can-while-the-player-moves
AI. The rest of us have simple projects that aren't going to benefit
from an integrated SETI@HOME-class client.
Given you have something that you want to do that would take unlimited
CPU, then I see your point that you would want to make your program
use all available CPU. However, I don't think that's an extremely
common case.
I'm just saying that the CPU is a device for turning electricity into fun.
If you can use more of the CPU to make more fun, then do so. Some games
really do have an upper limit of instructions per second that they can
make use of. Otherwise, I think there's a big pile of unused fun in the
land of wind and ghosts.
I had a lot more fun with Super Mario 3 on the NES (8-bit?) than I
have with many 3D games. I've had even _more_ fun with 3D games that
implemented cool ideas that simply weren't possible on the NES. I
would argue that CPU cycles are just part of the tool, and unless you
have an uber-cool idea for having fun that happens to _need_ CPU
cycles, using more cycles does not automagically mean more fun. I
have a lot of fun playing board games like "Settler of Catan" as well,
and they don't use _any_ CPU cycles. :-)
I'd like to see this uber-cool, CPU-intensive game when you finish it.
I'll even test it on my 333Mhz G3, if you want. :-)
~ Nathan