又是Job system

在上一篇文章中，我照自己的需求實作了一個job system，其中有個功能不是很令人滿意。

假設目前有job A與job B，A做完才能做B。在上文架構中，能夠在執行job A時產生job C，且可允許C做完才會做B。但是在使用該架構時，無法以直觀的方式達成這功能。理由是job內部不能等待其他job完成，更精確地說是任一worker不能以任何原因等待其他worker。效率問題暫且不提，若每個worker都產生新的job然後等待其他worker完成該job，就沒有worker會做事了。為了減少worker等待的情況，該架構還實作了限制特定job同時被執行的數量。

現在有新的方法可以解決這些問題了，Naughty Dog在GDC 2015發表了他們的job system，
裡頭提到利用Fiber使得job內的等待動作成為可能。原理是job要等待時就把目前的fiber存起來，然後從fiber pool拉出一個新fiber來執行別的job；要切換回等待中的job時，就把目前的fiber丟進pool裡，再還原先前暫存的fiber。

此法可使所有worker無時無刻都在做事，且由於等待的限制解除，job程式碼的撰寫也變的更直觀。這個方法看起來太美好了，因此我又實作了一份job system。這次的實作目標有以下幾點：

• 使用boost coroutine來搞定fiber機制
• 拔掉manager thread
• 拔掉限制特定job同時執行數量的功能
• 保留其他已實作的功能

以下再貼一次之前的測試數據來對比新架構的效能，設定Job數量為2000個。值得一提的是新架構為了測試Fiber切換效率，特地新增一個job專門用來送出2000個job，並等待該2000個job完成。2000個job的程式碼與上篇文章相同。

對照組，完全不使用平行處理，測試1000次得到的平均時間迴圈10000，需時23.343ms

使用我的簡化版Doom3 BFG Job架構，測試1000次得到的平均時間

使用上篇文章架構測試1000次得到的平均時間
使用Fiber的新架構，2000+1個job測試1000次得到的平均時間這回總算是全面贏了我的簡化版Doom3 BFG，主要應是少了job list內sync機制的關係。Worker在衝刺job list的時候不需要每執行一個job就檢查一次sync，也沒有被sync中斷的可能，切換job的成本可減到最低。以往一直認為coroutine在多核心環境下無用武之處，要求效能的程式會選擇使用thread而不是coroutine，現在看來我錯了，而且錯得很開心。