[haiku-development] Re: On timeslices and cycles
- From: Christian Packmann <Christian.Packmann@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 16 Mar 2009 12:02:49 +0100
Ingo Weinhold - 2009-03-14 01:59 :
On 2009-03-13 at 17:03:44 [+0100], Urias McCullough <umccullough@xxxxxxxxx>
wrote:
I bring this up because in the hardcore distributed computing camp,
the developers and users alike, are always seeking out new ways to
make their client apps run faster on each target OS, and OSes with
"weak" threading control are usually avoided. Most of these
applications have even user-configurable control over the affinity and
thread count.
This doesn't convince me, that hard affinity is needed for this purpose. In
case the computer is mostly idle -- which I guess is the case most of the
time -- soft affinity will result in the same scheduling as pinning the
threads manually to the CPUs.
Not at all. The OS would need complete knowledge of the threads code mix
(int/FP/Vec), inter-thread communication behavior, memory access patterns
and cache usage to ensure the same scheduling behavior as can be achieved
with hard affinity. You're still thinking of SMP systems with identical
single-core single-thread CPUs. Try to move into the 21st century, please.
Hard affinity can be very useful on SMT systems by scheduling one
int-heavy and one FP-heavy thread to the same core, to make maximum use of
execution resources.
In some cases hard affinity may also be indispensable for achieving
maximum efficiency for CPUs with asymmetric cache structure like Intels
Core2 quads. By scheduling threads with high communication on the same
core pair, you can use the very fast communication over the shared L2
cache instead of having to hit the FSB, which is much slower than L2
transfers and also competes with memory and I/O traffic on the FSB.
> In case the computer is fully busy (like
compiling on all CPUs), the low priority threads won't run, so the behavior
will be the same as well. For the inbetween cases I have no idea what will
happen. This will mainly depend on CPU and memory usage of the involved
threads.
Anyway, introducing hard affinity -- which guaranteedly will be abused by
application developers who think they know what they are doing --
Yeah, horrible. All the kind of evil things one can do with hard affinity.
When one considers the havoc and terror which such programs wreak on
systems with hard affinity like Windows, Linux, AIX... eh, what problems
exactly, come to think of it? I've never heard of a single case where hard
affinity caused problems for a user. Care to provide a link?
Besides, hard affinity can not introduce any problems I can't create right
now by creating a high number of high-priority threads. The scheduler
needs to be able to handle such cases to maintain a usable system on
single-core/CPU systems anyway. The fact that possibly misbehaving threads
are fixed to some CPUs doesn't change anything. That's certainly not a
technical reason against hard affinity.
Besides, bringing such a point up in context of an OS where any program
can switch off the CPUs at will seems a bit... absurd.
> so that
people can squeeze 0.01% more throughput for distributed applications out of
their machines seems hardly a good bargain.
The gains can be much higher. Depending on the system and workload, 20-30%
may be easily achievable - but this depends on the specifics of code,
thread layout, communication behavior and of course the hardware the code
is running on.
Oh, and of course this doesn't apply only to DC, but all other
calculation-intensive programs like video transcoders, batch image
processing, and whatever else enterprising developers may come up with.
> Besides, from an environmental
point of view, I'm not even sure I still like those projects.
Yeah, I'm beginning to see where you come from. Wasting kWh upon kWh for
rebuilding Haiku over and over and over again is Good(TM), but
participating in DC efforts for finding cures to AIDS and cancer is bad.
Because Haiku is more important than human lives?
Apart from the medicine-related projects, lots of basic research in all
sciences is turning to DC in a big way. The majority of DC projects are
about physics, particle physics, chemistry, biology, climate prediction,
mathematics. Being anti-DC makes you anti-science automatically. If you
want to go back living in caves that's totally okay, but please don't
stand in the way of those parts of humanity who like the concept of progress.
Oh yeah, and of course running DC projects is much more
environment-friendly than running these calculations in HPC installations.
The latter require extensive cooling due to the high density of computing
equipment, where the cooling often uses up as much energy as the computing
hardware. Which doubles the energy consumption compared to running the
same code on distributed systems, where no additional cooling is required.
As the need for performing these calculation will not go away, you can
only choose how they are performed. DC is obviously the superior choice
from an environmental POV. Not providing an optimal environment for DC is
ethically irresponsible, this will only lead to a waste of energy compared
to the amount of computations accomplished.
After clearing this up, can we have a re-vote please? All votes against
hard affinity will automatically unveil you as the anti-science,
anti-progress and anti-environment scumbags you are. ;-)
Christian
p.s.: Hint: don't mix technical and ethical issues, EVER. HTH.
Other related posts:
