Print indd

Applicability on Other Platforms. In order to validate this optimization
with other platforms, we set-up a similar test case on Gem5 simulator [
1
].
In line with the current MPSoC architecture, the simulated system is made
of clusters of 4 Alpha cores sharing L2 caches. Each core owns its private L1
cache. However, this system differs from the TSAR system in two major points:
(1) Clusters are linked to each other by a crossbar interconnect and not any-
more by a NoC. Hence there is no time gap to access different distant L2 caches.
(2) The L2 cache policy is a round robin like policy. In TSAR platform each L2
cache is associated to a memory section whereas is this Gem5 platform cache
line are spread over L2 caches according to a circular policy. Regarding the
software environment, the linux kernel run is the 2.6.27. The micro-benchmark

---

Optimization of the GNU OpenMP Synchronization Barrier in MPSoC
67
(Listing
1.1
) was compiled with a GCC 4.7.3. The implementation of the barrier
mechanism is the same in this GCC version and the version 4.8.2 used with the
TSAR platform.
We used the previous methodology on this platform, running 400 loops of
the Listing
1.1
and measuring by a side channel the “release phase” duration
for platforms made of 8, 16 and 24 cores (Table
1
). Considering components
as perfect (caches, interconnects, ...), the simulation platform discards memory
access delays and contention issues coming up when increasing the number of
threads. This is why the measured time are the same for the three platform sizes.
Thereby we can notice the large gain provided by our optimization, around 91%.
It confirms the attractiveness of our optimization for different kinds of MPSoC.
Moreover, we can theoretically enlarge these experimentations to affirm that
our optimization is working for all kinds of platforms. Indeed, our optimization
aims at removing unnecessary function calls at the middle-ware level. The alter-
native strategy proposed is fully independent of platform since this function is
still non-useful whatever the platform is. Hence by skipping it, we can guarantee
a time saving. However, the amount of time saved depends of the host system.
Table 2. GNU OpenMP library optimization results for 40 runs (20 with optimization,
20 without) of the IS (class S) NAS Benchmark reference application for 16 threads
Total release time Total execution time
IS with optimization
93393049 cycles
1069602910 cycles
IS without optimization 162493024 cycles
1228012444 cycles
Gain with optimization
42.5%
12.9%