The Art of Profiling and Benchmarking: Making Software Faster on AArch64

-

 As the SPO600 course end nears, I have learned a lot about profiling and benchmarking, important skills for making software faster. This blog post will talk about these topics and what I learned in the course.

What is Profiling and Benchmarking

Profiling is looking at a program to see which parts use the most resources like CPU time and memory. Profiling helps to find slow parts that need fixing.

Benchmarking is running tests to measure how fast a program is. This helps compare different versions of the software or different ways of doing things.

Tools for Profiling and Benchmarking

In the course, we use some tools to profile and benchmark our code. These include:

  1. perf: A powerful tool for profiling on Linux. It gives details about CPU use, cache hits, and more.
  2. gprof: A GNU tool that shows time spent in each function.
  3. Valgrind: Mostly for finding memory leaks, but also has a profiler called callgrind for looking at function calls.

Steps in Profiling and Benchmarking

1. Find the Target Code

First step is to find the part of the code that needs optimization. This could be a function or module that is slow.

2. Collect Profiling Data

Use tools like perf or gprof to collect data on the program's running. For example, running perf:

sh
perf record -g ./my_program
perf report

This makes a report showing which functions use most CPU time.

3. Analyze the Data

Look at the data to find slow parts. Functions using a lot of time are good targets for optimization.

4. Make Optimizations

Optimizations can be:

  • Better algorithms: Using more efficient algorithms.
  • Refactor code: Making code simpler and faster.
  • Use hardware features: Using SIMD instructions and other special features.

5. Benchmark the Optimized Code

After optimizing, benchmark the new code to see if it’s faster. Run the same tests to compare.

Example: Optimizing a Sorting Algorithm on AArch64

We worked on making a sorting algorithm faster. Here is the process:

Initial Profiling

Using perf, we found that the compare function in quicksort was slow, using over 40% of CPU time.

Optimization

We made the sorting algorithm faster by:

  • Changing to introsort: It switches to heapsort when recursion is too deep.
  • Using SIMD instructions: Writing a custom compare function with ARM’s NEON intrinsics.

Benchmarking

After optimization, we benchmarked the new code. It was 30% faster than the original, showing our optimizations worked.

Comments

Post a Comment

Popular posts from this blog

Exploring Retro Arcade Days - Simple Yet Challenging Breakout

-
Lab-2  Introduction  In this lab I got to explore and relive the experience that my dad gained . I wanted to build a game in 6502 assembly language using an online emulator . With the help of online resources and YouTube tutorials , I managed to create a simple game  Concept To experiment , I chose a simple breakout game in which the player has to judge an incoming ball(pixel) , which bounces off of a platform . Player can reposition the platform along the X-axis and the velocity of the ball increase each time it bounces off the platform. Player earns a point each time the ball bounces off the platform . Game ends when the ball hits the bottom of the screen . Development Process Using a 6502 assembly language emulator and a text editor, I began writing the code for my game. I defined variables for the ball's position, velocity, paddle size, score, and collision detection flags. Then, I set up the initial game state, including placing the ball and paddle on the screen. Nex...
Read more

Exploring Assembly Language (Lab-1)

-
Introduction: In the realm of computer programming and analysis, delving into assembly language can be both daunting and exhilarating. As a student at Seneca in computer programming and analysis, I recently embarked on a lab journey exploring the intricacies of assembly language, particularly focusing on the 6502 architecture. In this blog post, I'll share my experiences, discoveries, and insights gained from the lab experiments. Calculating Performance and Modifying Code: In one of the lab experiments, I initially tackled the task of calculating the execution time of a code snippet aimed at filling a bitmapped display with a solid color. After analyzing the code and considering a clock speed of 1 MHz, I calculated the execution time to be approximately 1.321 milliseconds. This involved dissecting the assembly code, understanding the purpose of each instruction, and considering optimization techniques. Here is the original code : lda #$00      ; Load accumulator with lo...
Read more

Lab-3

-
  Exploring Assembly Language on x86_64 and AArch64 Introduction In this lab, we dive into the intricacies of assembler on both x86_64 and AArch64 architectures. We'll explore code examples, disassemble object files, and write simple assembly programs to understand the core differences and functionalities between these architectures. Setting Up First, we unpacked the provided code examples: cd ~ tar xvf /public/spo600-assembler-lab-examples.tgz This created a directory structure under  ~/spo600/examples/ , containing various examples in C and assembly for both architectures. Building and Running C Programs We started with the C programs to establish a baseline: Building the C programs: cd ~/spo600/examples/c make Running the C programs: ./hello ./hello2 ./hello3 Observing the differences: hello.c  uses  printf() . hello2.c  uses  write() . hello3.c  uses  syscall()  directly. Disassembling C Binaries Using  objdump , we disassembled th...
Read more