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 Multithreaded Applications 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-