Hi Eric,
I don't thinks so
It depends on how "portable" the program needs to be. If supporting
Windows, OS X, Linux and other Un*x flavors is enough, then it's not
because there are two or three OS specific implementations that the
program is not portable.
On a four-core chip, what is a "CPU" and how much of the
"CPU" is used by one compute-bound infinite loop? One point
of view is that the "CPU" is active all the time, and hence
100% busy. Another says that three of the four cores are idle,
so the "CPU" is only 25% busy.
But wait! Suppose each core supports two "strands" of
execution, cycle-switching between the strands. So seven of
the eight strands are idle, and the "CPU" is 12.5% busy.
But wait! It turns out that the two strands on a core
share the core's lone execution pipeline, so that they can't
both retire an instruction at each cycle; they take turns.
So seven of the eight strands are idle, but one of the idle
strands would slow down the infinite-loop strand if it were
to become active -- so what fraction of the "CPU" is busy?
I happen to work for a company (soon to be but a memory)
that makes processor chips in various of these combinations.
Eight cores with thirty-two strands, eight cores with sixty-
four strands, four cores with eight strands -- and that's just
the company's own CPU designs; we also build systems that use
multi-core multi-strand processors from AMD and Intel. Having
used several of these myself, I can tell you: "CPU utilization"
is a non-portable notion even at the hardware level, never mind
what obfuscations the O/S contributes. (Hypervisors, anyone?)
Launch new EC2 instances when the load is too high?
Lower the "load" of your own Java program to let the OS be
more responsive?
The CPU utilization on the machine I'm using to write this
message can never, ever exceed fifty percent. Why? Because the
O/S believes that the system has two CPU's, but it actually has
just one CPU supporting two "hyperthreaded" execution strands,
only one of which can do anything at a given time. When my "CPU
utilization" is fifty percent, the system is saturated, busy,
incapable of performing more work. A program that says "Only
fifty percent? Hah! Plenty of headroom here!" is unlikely to
make good decisions ...
Application programs, by the way, have no business trying
to make such decisions. The fundamental problem is that the
program does not know its own importance in relation to other
activities on the system; "importance" is in the mind of the
system owner/operator/user, where the program can't detect it.
Does the program refrain from taking on more work because it
thinks the CPU's are overburdened? Bad choice: The user was
just about to migrate a couple more CPU's into the domain to
help the program get more stuff done. Does the program see
that the CPU utilization is low and decide to spawn twelve more
instances? Bad choice: The user was just about to steal a few
CPU's away and give them to a more important activity. The
program is "down in the trenches," and can't see enough of the
battlefield to make good strategic decisions about resources.
Not so many years ago it was easy to measure the utilization
of a disk: If it executed ten 10-ms I/O operations in the course
of one second, it was busy for 100 ms and its utilization was
ten percent. But then disks started to be able to handle multiple
operations simultaneously, and SAN's and NAS'es and such could
handle dozens at a time. Those ten 10-ms operations might overlap
and all be completed within a single 20-ms interval, leaving the
disk completely idle for 980 ms for a utilization of two percent.
"Disk utilization," once a crucial figure for capacity planning,
system tuning, and system management, became nearly worthless --
and what it meant varied widely from one disk subsystem to the
next. Something very similar has now happened to CPU's.
