SPO 600 Project - Stage 3

In this post, I will discuss my findings during Stage 3 of the project. For my previous stages, click here and here.

Before I start, I think I should mention how to performance improved in percentage. And there's the result:
[GeoffWu@aarchie tester]$ ./tester
Run #1
original version took 33339704 nanoseconds
modified version took 33237179 nanoseconds
hash match: y
difference between two versions: 102525 nanoseconds
percentage difference: 0.307516
Run #2
original version took 33302201 nanoseconds
modified version took 33231595 nanoseconds
hash match: y
difference between two versions: 70606 nanoseconds
percentage difference: 0.212016
Run #3
original version took 33366103 nanoseconds
modified version took 33270939 nanoseconds
hash match: y
difference between two versions: 95164 nanoseconds
percentage difference: 0.285212
Run #4
original version took 33349119 nanoseconds
modified version took 33346432 nanoseconds
hash match: y
difference between two versions: 2687 nanoseconds
percentage difference: 0.008057
Run #5
original version took 33358631 nanoseconds
modified version took 33268834 nanoseconds
hash match: y
difference between two versions: 89797 nanoseconds
percentage difference: 0.269187
Run #6
original version took 33353199 nanoseconds
modified version took 33301913 nanoseconds
hash match: y
difference between two versions: 51286 nanoseconds
percentage difference: 0.153766
Run #7
original version took 33249315 nanoseconds
modified version took 33269754 nanoseconds
hash match: y
difference between two versions: -20439 nanoseconds
percentage difference: -0.061472
Run #8
original version took 33306561 nanoseconds
modified version took 33333888 nanoseconds
hash match: y
difference between two versions: -27327 nanoseconds
percentage difference: -0.082047
Run #9
original version took 33376007 nanoseconds
modified version took 33293441 nanoseconds
hash match: y
difference between two versions: 82566 nanoseconds
percentage difference: 0.247381
Run #10
original version took 33342424 nanoseconds
modified version took 33367455 nanoseconds
hash match: y
difference between two versions: -25031 nanoseconds
percentage difference: -0.075073

Although the percentage difference is very marginal (around 0.1 to 0.3%), considering Tengine is originally designed for sites like Taobao, a Chinese online shopping website that is expected to handle hundreds of gigabytes of network traffic every single second (again, it is written in Chinese), I believe even a smallest amount of improvement would make a huge difference.

After I optimize the Murmurhash and pass all the unit tests, I opened a pull request, sign the CLA and submit my code to Alibaba, though they still didn't let me know whether they accepted or rejected my patch.

Reflection

I first heard of Tengine in around 2016, after I installed Wappalyzer on my Firefox basically just for my amusement. When I am spending my spare time watching videos on Bilibili (think of it as the Chinese equivalent of Youtube), I noticed a strange-looking T on the Wappalyzer. Driven by curiosity, I clicked on it, and that's how I found this web server.

I have to admit during the beginning of the project, I actually not very sure if I can handle it, since I don't have any experience with open source before. But as it turns out it is not as intimidating as it seems, and more enjoyable and fulfilling than what I imagine (I still can't forget how happy I am when I finally managed to get the unit test running).

Overall, Tengine is a decent program to work with - though I would be appreciated if they would write more detailed documentation on the unit tests - in particlar, what kind of dependencies it required. While Lua/LuaJIT isn't a dependency required by Tengine, the unit test does require it, as it tests the ngx_http_dyups_module, a module that is not compiled into Tengine by default. The module also requires the ngx_http_lua_module and either Lua/LuaJIT.

Comments

Post a Comment

Popular posts from this blog

SPO 600 Project - Stage 1

For the SPO600 course, I need to complete a project of identifying a CPU-intensive function/method - let's say a checksum or hash algorithm - that is implemented in a language that compiles to machine code (e.g. C, C++, or Assembler) in an open-source project, improving its performance, then get that optimization accepted by the upstream. For more information, click here . Find an open source package For this project, I chose Tengine , a fork of the web server nginx  developed by Taobao . When I'm reading its source code in Github, I noticed that it also uses the MurmurHash , just like nginx. Since MurmurHash itself is a simple hash function, it would be difficult to improve it (I still remembered my professor once said an easy program is the most difficult one to optimize), I decided to accept the challenge, because why not? Benchmark the performance on AArch64 As the function is very simple, testing its performance is much simpler than I imagine: I just extract the
Read more

SPO 600 Project - Stage 2

In this post, I will discuss my findings during Stage 2 of the project. For more details, click here . Before I should talk about how I optimized the Murmurhash2 algorithm, I would like to answer a question that I forgot to add on my stage 1 post - where is that algorithm is used ? After doing some research, I found out that Tengine, just like nginx, uses Murmurhash2 in the ngx_http_split_clients_module , which is often used for A/B Testing . Alright then, let's talk about how I optimized the algorithm. First of all, I think I should mention the optimization strategies I eliminated: In-line assembler : Given Tengine is meant to support a variety of platforms and CPU architectures, I honesty don't think it is a good option to use it - unless Jack Ma would give me a job afterwards :) Altered build options : At first I considered this option, since it is the easiest one, and planning to change its compile options to -O3/-Ofast, but after checking the cc (which listed all
Read more

SPO 600 - Lab 5

Image
In Lab 5, I will be looking at Algorithm Selection and how the algorithm affect the system's performance. For more information, click here . I will be doing this lab on Aarch64, and I will compile my programs with -O3 optimization. Original version Right now I will checking if it produces the same result every single time, how long it takes to scaling the sound samples, and how long it takes to run. (Note: to view how long it takes for the system to execute a command, type time before it. For more information, consult the man page of time .) In each run, the program always produces the same result, but the time of scaling the sound samples and the run-time in each run are slightly different. Yes, the difference is so small, but at the end the numbers are still different, right? Version 2 - Lookup table In this version, I will create a lookup table of all possible sample values multiplied by the volume factor. Like the original, in each run, it also always pr
Read more