Presburger Arithmetic and Its Use in Verification

3.2. SOME PITFALLS OF FUNCTIONAL PARALLELISM ON THE MULTICORE
ARCHITECTURE
aGCthreadforeachcoresoscalabilityofgarbagecollectionisbetter[19]. Come
back to two examples which have been introduced in Chapter 2, one of the reasons
for a linear speedup of π calculation (see Table 2.1) is no further significant memory
allocation except the input array. However, a sublinear speedup of MergeSort
algorithm (see Figure 2.3) could be explained by many rounds of garbage collection
occurring when immediate arrays are discarded.
False Cache-line Sharing
When a CPU loads a memory location into cache, it also loads nearby memory locations
into the same cache line. The reason is to make the access to this memory cell
and nearby cells faster. In the context of multithreading, different threads writing
to the same cache line may result in invalidation of all CPUs’ caches and significantly
damage performance. In the functional-programming setting, false cache-line
sharing is less critical because each value is often written only once when it is initialized.
But the fact that consecutive memory allocations make independent data
fall into the same cache line also causes problem. Some workarounds are padding
data which are concurrently accessed or allocating memory locally in threads.
We illustrate the problem by a small experiment as follows: an array which has
asizeequaltothenumberofcoresandeacharrayelementisupdated10000000
times [25]. Because the size of the array is small, its all elements tend to fall into
the same cache line and many concurrent updates to the same array will invalidate
the cache line many times and badly influence the performance. The below code
fragment shows concurrent updates on the same cache line:
let par1() =
let cores = System.Environment.ProcessorCount
let counts = Array.zeroCreate cores
Parallel.For(0, cores, fun i −>
for j =1to 10000000 do
counts.[i] ignore
The measurement of sequential and parallel versions on the 8-core machine is shown
as follows:
> Real: 00:00:00.647,CPU: 00:00:00.670,GC gen0: 0,gen1: 0,gen2: 0// sequential
> Real: 00:00:00.769,CPU: 00:00:11.310,GC gen0: 0,gen1: 0,gen2: 0// parallel
The parallel variant is even slower than the sequential one. We can fix the
problem by padding the array by garbage data, this approach is 17× faster than
the naive sequential one:
let par1Fix1() =
let cores = System.Environment.ProcessorCount
let padding =128/sizeof
let counts = Array.zeroCreate ((1+cores)∗padding)
Parallel.For(0, cores, fun i −>
let paddedI =(1+i) ∗padding
for j =1to 10000000 do
23