Huffman encoding parallelization Taavi Adamson

Transcription

1 Huffman encoding parallelization Taavi Adamson 1. Overview For my project I decided to develop a parallelization of Huffman encoding procedure. The topic was chosen due to my understanding of the subject and since Huffman encoding deals with large sets of data, speedup by parallelization might be useful. In computer science and information theory, a Huffman code is a particular type of optimaprefix code that is commonly used for lossless data compression. The process of finding and/or using such a code proceeds by means of Huffman coding, an algorithm developed by David A. Huffman. [1] Parallel application for key generation, encoding and decoding were developed to process large text files. Key generator reads the text file and writes a new key file. Encoder uses the keyfile to encode given input text file. Decoder can be used to get the initial text back from encoded text using a generated key. Key generator and encoder were developed as parallel applications, decoder was written in a serial fashion only to prove the concept of encoding. Biggest emphasis was on the encoder from which all timing results are aquired. 2. Implementation 2.1. Structure The project was developed using Python programming language with MPI bindings and it consists of 4 files, 3 of which are to be run and one which provides all common functionality: Runnable: 1. keygen.py 2. encode.py 3. decode.py Utilities: 4. treeutils.py

2 Each of the runnables is parallelized and provides part of the complete functionality of the project. The projet was developed to be run in University of Tartu HPC Rocket cluster. All of the abovementioned files are uploaded to a repository located at: For each of the runnables a run script is provided which makes it easier for a user to run these on Rocket cluster. Python programming language was chosen due to time constraints. It is the easiest to use for such small scale projects. For best efficiency another programming language like C should be used since Python is only interpreted and not compiled for specific system. This means that it cannot use very fast methods directly from CPU which makes it significantly slower Usage A run script on Rocket cluster can be used using a command structured as: bash <script name> <number of processes> <name of file> The file name should not include its extension, so for example for a file named textfile.txt one should input only textfile One full example: bash run_keygen 32 big Before any encoding one should generate a key using provided key generator keygen.py for the file wished to be encoded. For example: bash run_keygen 32 big creates a file named big_key.txt bash run_encode 64 big creates a file named big_encoded.txt bash run_decode big creates a file named big_decoded.txt Keygen command creates a key file named after the initial file: <initial file name>_key.txt and encoder creates a file named: <initial file name>_encoded.txt. The files <initial file name> and <initial file name>_decoded.txt should contain exactly the same data. 2

3 Processing time (ms) 3. Scaling results 3.1. Parallel time For any parallelization of an algorithm one should asses its gain. One way of doing it is to calculate achieved speedup. Also, scaling should be evaluated. Figure 1 and 2 show results of strong and weak scaling results respectively Strong scaling Result scaling Ideal scaling Number of processes Figure 1. Strong scaling results Figure 1 results were achieved by running encoder on a fixed problem size (6,5 MB text file) with increasing number of processors. As can be seen from figure 1, the program scales very well, very close to ideal until process counts of 30 or more. After that the processing time stays relatively the same and starts rising due to increasing communication costs. 3

4 Processing time (ms) Weak scaling Problem size (* initial) Initial process count 2 Initial process count 8 Ideal scaling, initial process count 4 Figure 2. Weak scaling results Figure 2 results were achieved by running encoder on increasing problem size with increasing number of processors. Different lines mean different starting points of process count selection. Figure 2 suggests that the programs weak scaling could be improved. Ideally the processing time should remain the same if S / p = constant, where S is the problem size and p is the number of processes. This seems not to be the case, especially with higher process counts Serial time The application also has a small serial part mostly due to I/O operations which are performed in only one master process. These times were measured and were relatively small about 300ms for the 6.5 MB file and scaled linearly for bigger files. 4. Compression Since this project is meant to be proof of concept for parallelization of the algorithm then no compression is achieved by current implementation. At the moment encoded info is written in binary string where every symbol takes up 8 bits. This means that encoded data is several times bigger than original. 4

5 For real-use implementation one should convert the binary string into bytes and write file using those bytes. In that case compression ratios of 8 or more could be achieved. This measn that resulting encoded file is 8 times smaller that the original, but without any data loss. 5. References 1. Huffman, D. (1952). "A Method for the Construction of Minimum-Redundancy Codes" 5