Tonyyanxuan's hackpad
Editor : Yan-Hsuan Chuang
 

NOTES

  • NASM
  • ARM
 

Implementations

 

Homewroks 2015

Week 2 +2015q3 Hw1_ext
Travis (CI), Jenkins ===> Git Hook 
 
[ Homework 1 ]
上面這三個利用阿基米德法求得 GCD 的 C 語言程式碼,加上必要的 benchmark 機制,並且觀察最終輸出的 ARM 組合語言。開發流程見以下:
  • 寫出一個 benchmark,分別測試上述程式在 Intel x86 架構 (就是你的桌上型或筆記型電腦) 上的運作效能。參考框架: benchmarks
  • 測試條件
  • 兩個介於 2 9999 的數值作為輸入,利用輾轉相除法找出最大公因數,應該要涵蓋所有組合。應該執行一段可觀的數量後,計算出平均耗費時間,並且針對三個不同的程式碼作輸出
  • 關閉編譯器的最佳化, CFLAGS 使用 -O0 (後面是數字零)
  • gcc -S 觀察 ARM 組合語言的輸出,比較這三組對應的實做。記得要加上 -mcpu=cortex-a15,這樣才會有 udiv 和 sdiv 指令
 
  • 參照呂鴻同學的方法,使用clock_gettime 來跑,接著使用pointer to function來測試,結果是v2, v3的效能差不多,感覺怪怪的,還要在檢查一下
 
 
[ Homework 2 ]
Intel x86 架構執行本週 Quiz 題目 (見下方 cache)撰寫必要的 benchmark 系統,找出效能最佳化的策略並且實做出來。注意:我們最在意能否快速找到電話簿裡面指定的 Last name
  • Cache(bit) : 32*1024 (32K)
  • 32*1024 / (16*8) = 256(只能存256筆)
  • 可以最佳化成 32*1024  / 32 = 1024 筆 (hash function)
  • 可以假設 boundary 是2億,去想如何處理 PHONE_BOOK
  • Pentium 4: 512K
 
  • 嘗試產生一個array of pointers , 接著先把1024個LastName的pointer放進來在丟進去比對,結果是一個徹底的失敗,跑超久都沒有結果,直接怒ctrl+c,或者也有可能是我的pointer寫得太爛了,導致意料之外的結果才跑不出來
  • 嘗試改成
while(pHead->LastName != NULL)
也是一個徹底的失敗,兩個時間根本沒有差別,應該是因為都產生了一樣的行為吧?
  • benchmark會遇到需要把cache flush的問題,最笨的方法就是產生超多運算,多到能蓋過L2的cache,但是會等很久,很智障
  • 應該要嘗試echo 3 > /proc/sys/vm/drop_caches 
 
  • cache miss test
  • 太神啦!我把struct改成