SPO600 - Project Stage 2

-

Introduction:

This tool generates three versions of the function specified as the second argument. Then, while building the main output file from these functions, this tool employs the ifunc capability to select the best method. 

The tool was written in Python, while the ifunc resolver function is written in C. In this blog, I will explain the tool's working mechanism and limitations, as well as the procedure for testing the tool.


Accessing the tool:

The tool is hosted on GitHub. The tool is available for download at https://github.com/puja1102/SPO600Project. The GPL version 2 licence governs the use of this tool.

The tool's main files are as follows:

  1. tool.py: the main tool written in Python that builds the functions and generates the output binary files using the best SIMD implementation.
  2. template.txt: This is a text file containing the template for the ifunc function, as well as the resolver function for the ifunc. The ifunc.c file is created using this template.

This tool is used to generate the main output binary file. However, it will also generate a number of output files or c files. The files created after running the tool are listed below.

main: The output binary file.
ifunc.c: This is a c file that contains the ifunc function, which is the resolver that determines the best SIMD version at run time.
ifunc.h: This is the header file for ifunc.c, and it contains function prototypes.
function1.c: This is ASIMD's first version of function.
function2.c: This is the SVE function's second version.
function3.c: For SVE2, this is the third version of function.
function1.o: output file generated after constructing function1.c
function2.o: After building function2.c, an output file is created.
function3.o: After building function3.c, an output file is created.
build.sh: A bash script file containing a series of gcc commands for creating function output files as well as the main binary output file. This is used by the tool to create and link all of the output files.

Limitations:

  • The tool's first limitation is that it can only accept two arguments. The first argument must be the main.c file, and the second argument must be the.c file that contains the vectorized function.
  • The tool's second and most significant limitation is that it currently accepts only the function named "adjust channels." The vectorized function must be called adjust channels. This tool will only work if the function to be vectorized is void and returns nothing.
  • This tool lacks proper exception handling and input data validation, which means that if any arguments are invalid or are in the wrong order, or the second argument does not contain the single function, this tool will break and will not function properly.
  • Aside from these, this tool has a few minor bugs as well as some permitted limitations.

Working:

The first step is to open the function.c file provided as the second argument. Previously, I used the sys library to access an array of arguments via sys.argv. This allowed me to obtain the filename for both the first and second arguments. By doing so, I was able to store the names of both files in two variables. Then I read the function.c file using the open() function (which contains the function).

I changed the function name and the print f function three times after reading the function. For Advanced SIMD, I added the _asimd suffix to the function name (in this case, "adjust channels").

The following step was to write the ifunc.h header file. I needed the functions prototype to do this. I used.find to extract the prototype (). All three functions' prototypes were extracted and saved in three variables. Then I concatenated all three prototypes into a new file called "ifun.h." As a result, ifunc.h was created as a header file.

It was now time to write the ifunc.c file. To begin, I created a template. I used the open source code for the resolver provided by professor to create a template.
This code is licenced under the GNU General Public License version 2+. The source code can be found here: https://github.com/ctyler/ifunc-aarch64-demo/blob/main/ifunc-test.c

The template was then read from this template.txt file in tool.py and stored in variables. Then I used.replace() to replace place holders denoted by a #.
The final step was to create three functions to generate three output files, which were then linked together using ifunc to generate the main binary output file.

The commands to create three versions of functions are as follows:
gcc -g -O3 -march=armv8-a -c function1.c -o function1.o 
gcc -g -O3 -march=armv8-a+sve -c function2.c -o function2.o 
gcc -g -O3 -march=armv8-a+sve2 -c function3.c -o function3.o

Then I added the final gcc command to link all the files together to generate the final output binary file - main.

Comments

Post a Comment

Popular posts from this blog

Lab 5 - Algorithm Selection Lab

-
In this lab, I wrote a set of programs that generates sound samples in a data array. It generates 5000000 samples as specified in the provided "vol.h" file, then scales the samples by a factor of 0.75 and returns them to the array. As a result, the program generates and displays a sum from the output array. To test the run time for each program, we'll use the command "time./programName," which will run the program and output the results as well as the time it took to run it. The program's real time is the sum of two sections: "user time" and "system time." Task 1: I obtained the base run time data we will work with when I ran the initial program, "vol1." This program runs with the volume factor unchanged. This allows us to test the other programs and observe any significant changes in run time data. Running the same program will not always produce the same results; there may be slight differences. This could be due to initial r
Read more

Auto Vectorization

-
 I'm working on a blog post about the concept of automatic vectorization in parallel computing, which can help reduce the number of cycles and chains in loops. It means that instead of scalar implementation, code can be converted to perform vector operations, which means a single operation can be performed on multiple operands. The GCC compiler is sophisticated enough to use vectorization to optimise code and improve performance. It is possible to accomplish this by using optimization flags such as -03 and -ftree-vectorize. AArch64 supports three extensions: SMID (Single Instruction, Multi Data), SVE, and SVE2. SVE  and SVE2 Scalable Vector Extension 2 (SVE2) is an armv9 extension that provides variable-width SMID capability. The main difference between SVE2 and SVE is the functional coverage of the instruction set. SVE and SVE2 both allow for large amounts of data to be collected and processed. For an aarch64 system, run the following command to enable SVE: gcc -g -O3 -c march=arm
Read more