techniques to exploit hardware parallelism. Unfortunately, many details
about developing concurrent applications on modern processors have
mostly slipped through the cracks,
only to be found in white papers,
blogs, and similar watering holes of
the performance community.
IllustratIon by mIkael hvIDtfelDt Chr Istensen
What developers are finding more
often than not is that sizing parallel ap-
plications is not as straightforward as
it once seemed. Until quite recently the
one or two processors available within
a single processor chip did not cause
more contention for shared resources
than perhaps two software threads
fighting over shared cache space.
Nowadays, not only are there several
levels of sharing between logical CPUs
(shared execution pipeline, floating-
point units, different cache levels,
among others), but also these many
more CPUs make that sharing a much
more complicated problem.
This new landscape poses new questions for you as a developer and system
administrator: How many threads
should your workload create? What resources do they require? Are all threads
equally important? How should you
size shared data structures? What
should you tell the operating system
(or more generically, the underlying
layer) about your application?
Provisioning threads in
Although the simple classic recipe
of one software thread for each logical CPU may still be valid in some
cases, it can no longer be applied indiscriminately. 2 Parallel applications
must know which portions of their
program may require resources that
are not widely available in the system.
With that knowledge and some under-