Programming Multi-Core Processors based Embedded Systems A Hands-On Experience on Cavium Octeon based Platforms Lab Exercises

1-2 Lab # 1: Parallel Programming and Performance measurement using MPAC

1-3 Lab 1 – Goals Objective Use MPAC benchmarks to measure the performance of different subsystems of multi-core based systems Understand accurate measurement method for multi-core based systems Use MPAC to learn to develop parallel programs Mechanism MPAC CPU and memory benchmarks will exercise the processor and memory unit by generating compute and memory intensive workload

1-4 Observations Observe the throughput with increasing number of threads for compute and memory intensive workloads Identify performance bottlenecks

1-5 MPAC fork and join infrastructure In MPAC based applications, the initialization and argument handling is performed by the main thread. The task to be run in parallel are forked to worker threads The worker threads join after completing their task. Final processing is done by main thread

1-6 MPAC code structure

1-7 Compile and Run on Host System (Memory Benchmark) Memory Benchmark host$ cd / /mpac_1.2 host$./configure host$ make clean host$ make host$ cd benchmarks/mem host$./mpac_mem_bm –n -s -r -t For Help host$./mpac_mem_bm –h

1-8 Cross Compile for Target System (Memory Benchmark) Cross Compile on Host System Go to Cavium SDK directory and run the command host$ source env-setup (where is the model of your target board. E.g. OCTEON_CN56XX) host$ cd / /mpac_1.2 host$./configure --host=i386-redhat-linux-gnu --target=mips64-octeon-linux-gnu export CC=mips64-octeon-linux-gnu-gcc host$ make clean host$ make CC=mips64-octeon-linux-gnu-gcc

1-9 Run on Target System (Memory Benchmark) Run on Target System Copy executable “mpac_mem_bm” on target system target$./mpac_mem_bm –n -s -r -t For Help target$./mpac_mem_bm –h

1-10 Performance Measurements (Memory) (a) 4 KB (b) 16 KB (c) 1 MB (d) 16 MB $./mpac_mem_bm –n -r –s 512 –t i$./mpac_mem_bm –n -r –s 2048 –t i $./mpac_mem_bm –n -r 100 –s –t i$./mpac_mem_bm –n -r 10 –s –t i Results taken on Cavium Networks EVB 5610 Board

1-11 Performance Measurements (Memory) Data sizes of 4 KB, 16 KB, 1 MB and 16 MB are used to exercise the L1, L2 Cache and main memory of the target system. Cavium Octeon (MIPS64) CN5610 Evaluation board is used as System under Test (SUT). With Data more than the size of L2 Cache (2 MB), the throughput is expected to not scale linearly. The linearity is seen because of the low latency interconnect used in place of system bus. Throughput scales linearly across number of threads for all cases.

1-12 Compile and Run on Host System (CPU Benchmark) CPU Benchmark host$ cd / /mpac_1.2 host$./configure host$ make clean host$ make host$ cd benchmarks/cpu host$./mpac_cpu_bm –n -r For Help host$./mpac_cpu_bm –h

1-13 Cross Compile for Target System (CPU Benchmark) Cross Compile on Host System Go to Cavium SDK directory and run the command host$ source env-setup (where is the model of your target board. E.g. OCTEON_CN56XX) host$ cd / /mpac_1.2 host$./configure --host=i386-redhat-linux-gnu --target=mips64-octeon-linux-gnu export CC=mips64-octeon-linux-gnu-gcc host$ make clean host$ make CC=mips64-octeon-linux-gnu-gcc

1-14 Run on Target System (CPU Benchmark) Run on Target System Copy executable “mpac_cpu_bm” on target system target$./mpac_cpu_bm –n -r For Help target$./mpac_cpu_bm –h

1-15 Performance Measurements (CPU) (a) Integer Unit Operation (b) Logical Unit Operation $./mpac_cpu_bm –n -r –a 1 –u i $./mpac_cpu_bm –n -r –a 1 –u l Results taken on Cavium Networks EVB 5610 Board

1-16 Performance Measurements (CPU) Integer Unit (summation) and Logical Unit (string operation) of the processor are exercised. Cavium Octeon (MIPS64) CN5610 Evaluation board is used as System under Test (SUT). Throughput scales linearly across number of threads for both cases.

1-17 Measurement of Execution Time Measuring the elapsed time since the start of a task until its completion is a straight-forward procedure in the context of a sequential task. This procedure becomes complex when the same task is executed concurrently by n threads on n distinct processors or cores. Not guaranteed that all tasks start at the same time or complete at the same time. Therefore, the measurement is imprecise due to concurrent nature of the tasks.

1-18 Cont… Execution time measured either globally or locally. In the case of global measurement, execution time is equal to the difference of time stamps taken at global fork and join instants. Local times can be measured and recorded by each of the n threads. After thread joining, the maximum of all these individual execution times provides an estimate of overall execution time.

1-19 Definitions LETE: Local Execution Time Estimation GETE: Global Execution Time Estimation

1-20 Cont… LETE GETE

1-21 The Problem Lack of Precision Some tasks finish before others Synchronization issue with large no. of cores Results not repeatable

1-22 Performance Measurement Methodologies For multithreaded case Get start time at the barrier (1) (2) (3)... (K) Repeat for N no. of iterations Get end time at the barrier For sequential case Get start time Repeat for N no. of iterations Get end time

1-23 Accurate LETE Measurement Methodology (1) (2) (3)... (K) Thread synchronization before each round using barrier Repeat for N no. of rounds Maximum elapsed time for the round

1-24 Measurement Observations

1-25 Accurate MINMAX Approach Repeat for N no. of Iterations Store thread local execution time for each thread for each iteration For an individual iteration store the largest execution time amongst the threads We have stored N largest execution time values Choose the minimum of that value to be your execution time. The MINMAX value!!

1-26 MPAC Hello World Objective To write a simple ” Hello World” program using MPAC Mechanism User specifies number of worker threads through command-line Each worker thread prints “Hello World” and exits

1-27 Compile and Run $ cd / /mpac_1.2/apps/hello $ make clean $ make $./mpac_hello_app –n