執行人: andy155224
重做 lab0 並彙整其他學員的成果。
宣告一個結構體 list_head
的指標 head
,然後透過 list.h 中的 INIT_LIST_HEAD()
來對 head
配置記憶體。
透過 list_for_each_entry_safe
逐一走訪 queue 中的每一個 element,並透過 container_of
計算每一個 element 的記憶體起始位置,計算出位置後再用 q_release_element
將整個結構體 element
所配置的記憶體空間,包含結構體內的其他結構體和指標變數所指向的記憶體一同釋放,最後再將 queue 的 head l
釋放掉,以保證整個 queue 的記憶體空間都被釋放。
原本的寫法如下:
但 qwe661234
點出上述程式碼在 element_t *n
成功配置,但 char *value
配置失敗時,會導致配置成功的 element_t *n
之記憶體沒有被釋放。所以修改為:
函式運作的邏輯和 q_insert_head
只差在將 list_add()
改為 list_add_tail()
。
strncpy
, snprintf
和 strlcpy
的差異。因為 strcpy
會存在潛在的 buffer overflow 的問題,所以應該用 strncpy
來限制寫入的位元組的大小。但是 strncpy
也並非是安全的,因為有可能會發生 dest
字串的結尾並沒有 null terminator 的問題,所以有了更安全的 strlcpy
能選擇。strlcpy
如果遇到寫入的位元組大小比 src
的位元組大小還要小的時候,會在欲寫入的位元組大小的最後一個位元填入 null terminator 。但是因為這需要安裝額外的 package 才能 include bsd/string.h
,所以我選擇使用 snprintf
來達到一樣的效果。
函式運作的邏輯和 q_insert_head
只差在將 list_first_entry()
改為 list_last_entry()
。
透過 list_for_each()
逐一走訪 queue 中的每個 element 並用 int len
來計數。
透過一個型別為 list_head
的指標變數 tmp
和一個布林變數 flag
,在逐一走訪 queue
中的每一個 entry 時,每當 flag
為 true 時將 tmp
指向其下一個 entry 的 list。這樣當走訪完整個 queue
後 tmp
就會指向 queue
的第 個 entry,然後再將其刪除。
但因為 flag
會反覆在 0 和 1 之間變化,造成以下程式碼在
不做任何處理的情況下會產生 次 branch。
要減少 branch 次數的其中一種做法是透過快慢指標來找尋中間節點,但因為 lab0 所使用的資料結構為 doubly linked-list,所以可以考慮到雙向的特性,用更少次的操作找到中間節點,如下:
透過兩個指標 right
和 left
,每次迭代時 right
會指向 right->next
, left
會指向 left->prev
,這樣一旦 right
== left
或是 left->prev
== right
,此時的 left
即為中間節點。藉由這種做法就能在比使用快慢指標還少的操作下同時也有較少的 branch 產生。
透過 list_for_each_entry_safe
來逐一走訪整個 queue,每次迭代時會比較 curr->value
和 next->value
是否相同,如果相同的話將 curr
刪除並釋放記憶體空間,並把布林變數 flag
設為 true 以在 curr-> value
和 next->value
不同時將 curr
刪除並釋放記憶體空間。
透過 list_for_each()
逐一走訪整個 queue,每當布林變數 flag
為 true 時用 list_move()
將 node
移至 tmp
前,最後再將 node
和 tmp
指向 node->next
以確保走訪的正確性。
透過 list_for_each_safe()
逐一走訪整個 queue 並將走訪到的元素用 list_move()
移至 head
後面,進而完成 reverse 整個 queue。
原本的想法是透過 list_for_each_safe()
逐一走訪整個 queue,同時透過 int countK
來計數,走訪時會將元素 node
移至 tmp
後面,每當 countK mod k == 0
時調整 tmp
的位置來完成功能。
但是實際的效果和預期的不同,因為這和功能所述的 Reverse the nodes of the list k at a time
,不一致,上述程式碼是每次都會執行 list_move
而非當 countK mod k == 0
時才將前面 k
個元素 reverse,差異如下:
而我想到的解決方式是額外宣告一個變數 int count
並將其設為 q_size / k
,也就是總共會發生的 reverse 次數。這樣就能透過 count
來避免額外的 reverse 發生,只有在 count > 0
時才會執行 list_move()
。
參考了 你所不知道的 C 語言: linked list 和非連續記憶體 ,思路是透過 Divide and Conquer 先遞迴將佇列拆分成 q_size
個子佇列,再兩兩排序合併,最後就會得到一個已排序的佇列。
因為 lab0 所使用的資料結構為 doubly linked-list,所以只需要從 queue 的尾部開始逐一反向走訪,並且不斷去比較 struct list_head *curr
對應的 element 的 value 是否大於 struct list_head *curr->prev
對應的 element 的 value,如果大於的話則將 struct list_head *curr->prev
對應的 element 刪除即可。
先透過 container_of
找出連接著各個 queue 的結構體 queue_contex_t *queue_head
的記憶體位置,然後逐一走訪相連著的 queue 並透過 mergeTwoLists()
將第二個至最後一個 queue 合併進第一個 queue 中。因為每一個 queue 預設都已排序,所以 mergeTwoLists()
完就會是一個已排序的結果。
之所以不先將所有 queue 都透過 list_splice_init
合併後再用 q_sort()
合併是因為每一個 queue 都已排序,若再執行 q_sort()
中 divide 顯而易見是多餘的。
在 list.h
中的 list_splice_init()
有提到 "The @list head will not end up in an uninitialized state like when using list_splice. Instead the @list is initialized again to the an empty list/unlinked state.",所以在迴圈中每當合併完兩個 queue 都需要 INIT_LIST_HEAD(queue->q)
。
lab0-c
將 list_sort.c 和 list_sort.h 放到 lab0
的專案下並修改 Makefile 使得在 make 時會編譯 list_sort.c
在 list_sort.c
中有使用到 likely()
和 unlikely
,這是在 linux/compiler.h 裡的巨集,顧將這兩個巨集的定義搬移至 lab0
專案中的 list_sort.c
中。
修改 list_sort.c
和 list_sort.h
,調整函式的參數並修改一些型別定義使得 list_sort.c
能在 lab0
中運作。
void *priv
移除nonnull()
list_sort.c
中定義的型別 u8
改成 uint8_t
merge()
中針對 struct list_head *head
去抑制 cppcheck 的檢查,因為 head
不會是一個 unassigned variable將 list_sort.c
中的 cmp()
都改成使用 strcmp()
來比較字串大小,並抑制 cppcheck 的 nullPointer 檢查。
console.c
中新增 parameter algo
藉由全域變數 algo
來選擇排序演算法要使用 q_sort()
還是 list_sort()
透過 add_param()
新增有關 algo
的說明,並且這樣就能使用 option algo
來變更 algo
的值,以此決定要使用哪一個排序演算法。
do_sort
讓 do_sort() 可以根據 algo
的數值來決定要使用哪一個排序演算法。
q_sort()
和 linux kernel 中的 list_sort()
之間的效能落差新增 trace-sort_algorithm.cmd
來測試自己實作的 q_sort()
和 list_sort()
各別在排序 10000、500000 和 1000000 個節點時排序所需要的時間。在這個實驗中會執行十次 trace-sort_algorithm.cmd
,並統計在不同節點數量的情況下的平均排序時間各別為何。
節點數量 | q_sort 平均排序時間 | list_sort 平均排序時間 |
---|---|---|
100000 | 0.0226(s) | 0.0213(s) |
5000000 | 0.236(s) | 0.2548(s) |
1000000 | 0.7739(s) | 0.6448(s) |
從十次測試的平均中可以看到,在節點數為 100000 時,list_sort()
優於 q_sort()
6%,在節點數為 500000 時,q_sort()
優於 list_sort()
7.4%,而在節點數為 1000000 時,list_sort()
優於 q_sort()
17%。
需要解讀效能落差的成因,以及你能否從中學習到其精髓。
lib/list_sort.c
並量化分析解讀 Linux 核心原始程式碼的 lib/list_sort.c
,設計實驗來量化分析,探討其實作手法,需要善用 perf 一類的工具。解析程式碼要有完整的圖文、數學證明,和如何達到 cache 友善。
首先先來分析自己實作的 q_sort()
和 linux kernel 中的 list_sort()
到底有何不同。
q_sort
採取的是 merge sort,也就是先不斷遞迴分割,直到每一個子佇列都只有一個節點後後再兩兩合併成一個排序過的佇列,而會對 cache 不友善的主因也是發生在 merge
這個階段。因為此做法採取的是將同樣 level 的子佇列都合併完之後才會繼續遞迴往上合併,直到成為一個和原本佇列大小為止。但是這種做法會導致一但要排序的子佇列的大小超過了 L1 cache 的大小,cache 中的子佇列會不斷的在不同層級的 cache 中搬移,形成 cache thrashing,對 cache 不友善。
而 list_sort
之所以能達到 cache 友善是因為其合併方式採取了一個特殊的作法:
每次合併時保持合併與不合併的子佇列比例不會大於 2:1,這樣能確保合併的子佇列的大小可以放到 L1 cache 中,進而避免 cache thrashing。而在註解中也有提到藉由 2:1 的比例,可以省下 0.2*n 次的比較操作。
那實作中是如何確保 2:1 的比例呢?
實際上這是一段非常精美的程式碼,只透過了一個變數 count
來紀錄目前讀到的節點數,每當 count
為 2 的冪時不合併,反之則合併,以下表格為
使用 Linux 核心的 Random Number Algorithm Definitions 來產生隨機數,作為上述排序程式 (包含 Linux 核心的實作) 的輸入,以檢驗鏈結串列的排序實作。