owned this note
owned this note
Published
Linked with GitHub
# 2016 q3 Homework1 raytracing
contributed by <`finalallpass`>
### Reviewed By <`TempoJiJi`>
* [commit 09dc206](https://github.com/finalallpass/raytracing/commit/09dc2069738955562719e9d5d65d12b88fa5fdbb)可以利用git reset等指令避免無意義的commit
* Openmp可以比較不同執行緒數量的結果
* 可以證明跟解釋爲何執行緒數量4跟8的差距，並附上實驗結果
* 還有很多不同的實做可以進行，應多做不同實做的實驗
### Reviewed By <`Louie Lu`>
* 善用 git rebase 來整理 commit，避免如 commit: 09dc206 的狀況發生
### Reviewed By <`RayPan`>
* 尚未闡明為何使用force inline後cache misses會增加
* 尚未釐清thread數目與core數量間的關係
---
```
git rebase -i 812caaa2dafba0d
pick bcba26f OpenMP
s 09dc206 22:51
```
* git commit 應該更易閱讀，讓後續維護的人能夠從中了解這個 commit 的修正與影響, e.g.
```
Author: finalallpass <thyen@hsnet.ee.ncku.edu.tw>
Date: Thu Sep 29 12:33:08 2016 +0800
Adding OpenMP support for improve performance
OpenMP can easily imporve performance by adding
one line on for loop, it still have some limit
but good enough for this case.
Performance compare with non-version:
100 202
105 495
```
* Reference 的名稱應該要不吝嗇的給予原作者 credit. e.g.
```
## 參考資料
[TempoJiJI raytracing 共筆](https://hackmd.io/MYQwpgnARsBMUFoBmAWAjADgSsBmLGSuArAgAwDsFKAJmmAGxJgbFA==?view)
```
---
* original version的執行時間為：
```
# Rendering scene
Done!
Execution time of raytracing() : 5.473432 sec
```
* 使用gporf來分析，會得到結果如下
能看到再dot_product, subtract_vector等部份消耗最多。
## loop uunrolling
* 先嘗試老師影片中使用的loop unrollng，展開mathtoolkit.h中所有的for迴圈，一般而言，會因為迴圈數目龐大造成展開後會大幅增加程式碼的長度，不過這裡只需要三行所以影響不大。
```
for (int i = 0; i < 3; i++)
out[i] = a[i] + b[i];
```
更改為
```
out[0] = a[0] + b[0];
out[1] = a[1] + b[1];
out[2] = a[2] + b[2];
```
得到結果
```
#Rendering scene
Done!
Execution time of raytracing() : 3.893162 sec
```
gprof分析
在時間上進步了！
## Force inline
* 那再來嘗試inline的部份，使用inline的話程式會直接去展開函數，減少overload。我們在函數後面加上來令CPU強制執行inline
```
# Rendering scene
Done!
Execution time of raytracing() : 2.180311 sec
```
* 還有gprof的分析
剛剛被強制執行inline的函數已經沒有被顯示出來了，因為他們已經在函數位置被展開。
>>>沒有執行inline的話呼叫程式會去呼叫函式，有的話會在函式位置直接展開。但要展開這個函式不是也要去讀說這個函式的內容是甚麼嘛？
>>>查了一下知道call function會有function prologue和function epilogue，這些都會衝擊效能。有關這方面的問題會再去找書來研究。
* 在[深入了解inline的優缺點、性能及使用指南](http://blog.csdn.net/acs713/article/details/42649949)中有提到說：May increase function size so that it may not fit on the cache, causing lots of cahce miss.這個缺點，所以我嘗試用phonebook中的perf工具來驗證cache-misses的問題。
* 使用inline之前：
```
200,289 cache-misses # 20.294 % of all cache refs
797,136 cache-references
26,722,398,637 instructions # 2.22 insns per cycle
11,965,663,673 cycles
```
* 使用inline之後：
```
212,135 cache-misses # 28.161 % of all cache refs
637,978 cache-references
13,560,212,154 instructions # 2.06 insns per cycle
6,585,484,004 cycles
```
相差了大約8%。不知道如果展開的函式越長會不會差異愈大。
## 使用OpenMP
* 多執行續可以讓一件事分給多個核心來執行，那可以用parallel這個directive來讓for迴圈平行運作。[參考網址](http://aaz-blogger.blogspot.tw/2011/03/openmp-parallel-construct.html) [參考網址2](https://kheresy.wordpress.com/2006/09/22/%E7%B0%A1%E6%98%93%E7%9A%84%E7%A8%8B%E5%BC%8F%E5%B9%B3%E8%A1%8C%E5%8C%96%EF%BC%8Dopenmp%EF%BC%88%E4%BA%94%EF%BC%89-%E8%AE%8A%E6%95%B8%E7%9A%84%E5%B9%B3%E8%A1%8C%E5%8C%96/)
* 在for迴圈前加上#pragma omp parallel for num_threads(64), private(d, object_color, stk)
```
# Rendering scene
Done!
Execution time of raytracing() : 1.663272 sec
```
* 執行時間被下降到了1.6秒左右。
>>>這邊不是很懂thread的數目跟core的數量間的關係。
>>>
>>>用lscpu得到我的threaf per core是1，所以照裡來說我應該一次只能執行4個thread才對，但是num_threads輸入8的效能會明顯比4還要好。
>>>[參考網址](http://stackoverflow.com/questions/47703/multiple-threads-and-performance-on-a-single-cpu)看了這篇之後，覺得應該可以想成一張桌子只能一人使用，但前一人再結束階段時後面排隊的可以先使用桌子進行準備的感覺。不過這樣要如何知道我要同時開多少thread來讓效能最佳化呢？
[參考共筆](https://embedded2016.hackpad.com/ep/pad/static/f5CCUGMQ4Kp)
[參考共筆2](https://hackmd.io/MYQwpgnARsBMUFoBmAWAjADgSsBmLGSuArAgAwDsFKAJmmAGxJgbFA==?view)
Google Drive
Gist
Clipboard
Sign in with Wallet
