2017q1 Homework4 (phonebook-concurrent)

tags:zhanyangch sysprog2017 week4

執行環境

Architecture:          x86_64
CPU 作業模式：           32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
每核心執行緒數：          2
每通訊端核心數：          2
Socket(s):             1
NUMA 節點：             1
供應商識別號：        　　GenuineIntel
CPU 家族：              6
型號：                  42
Model name:            Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
製程：                  7
CPU MHz：      　　　　　855.421
CPU max MHz:           3500.0000
CPU min MHz:           800.0000
BogoMIPS:              5587.06
虛擬：                  VT-x
L1d 快取：              32K
L1i 快取：              32K
L2 快取：               256K
L3 快取：               4096K
NUMA node0 CPU(s):     0-3

執行

• 可以發現 append 的時間大幅度的縮短
• THREAD_NUM 為 4 但加速不只 4 倍，除了concurrent 還用了其他優化手段，測試不同　THREAD_NUM 下的時間。

分析

• text_align 將每一行的長度調整為相同大小，長度不足的部份填入 '\0'，長度超過的部份則去除並出現警告。

append 所花費的時間沒有算入 text_align，是否造成實際執行跟測量有時間的差異

execution time of align : 0.090644 sec，平均 align 一行需要　0.090644/349900=0.000000259 sec，幾乎可以忽略。

• O_NONBLOCK 以 nonblock 的方式開起檔案
• mmap 將檔案內容映射到記憶體上，用記憶體的讀寫取代較緩慢的I/O
• entry_pool 先配置一大塊記憶體減少重複呼叫 malloc 所需要的時間
• append 每個 thread 先建立部份的 list 最後合併為一個

不同 THREAD_NUM 對 append 的影響

• 1 到 4 個 thread 對於　append 差異不大，超過 4 個 thread 反而會提高執行時間。
• 影響執行時間的主因不是 thread 數目，memory pool 和 mmap 的影響比較大。
• 彥寬的實驗中提到可以改為async
  

加入 thread pool

• 如果是因為每個 thread 完成的時間不同，造成要等慢的 thread，可以將工作切分的更細，提早做完的 thread 可以拿到新的工作。
• 使用 mergesort-concurrent 的 thread pool 實做
• 在 THREAD_NUM=4 下調整不同的 TASK_NUM
  
• 用 thread pool，不論在切割多少 task 下，皆比不用thread pool 表現差，可能的原因為 task quene 的 push 和 pop 比想像中的花時間
• findName 的有趣現象:在不同的 TASK_NUM 下呈現震盪，後來發現在原本的版本中修改 THREAD_NUM，也會發生類似情形

用 memory pool 的影響？需在仔細探討