本來只是對高體報告的記錄, 沒想到變成了對所有事情記錄的報告, 今天也算是遵從了昨天的規(guī)定, 不過有些地方還是需要改改的, 比如時間, 當然這個時間是需要改進的
今天天氣不錯, 準備下午去跑步, 所以午睡時間提前一點 1500-1600午休 1600-1730跑步,?
qbittorrent加了track的速度的確不錯, 最高基本3m封頂, 但是由于資源問題可能速度會下降
今天下午由于耳機未到, 所以去騎車了, 環(huán)城路一周->貴池路->合作化路
Arch
大約每篇論文占用兩篇的版面, 但是實際大小需要根據(jù)內(nèi)容進行調(diào)整, 比較新的論文適當增加內(nèi)容, 反之減少, 總結(jié)占據(jù)3篇
在"UCP"中大約算法標點大約有2200字左右, 而純字數(shù)應該也接近一千七八字左右, 再加上圖的話, 應該可以占據(jù)兩頁的面積
UCP
在 ucp中主要提出了兩部分的內(nèi)容, 資源monitor UMON與核心劃分算法, 這兩部分組成了這篇文章的核心工作, 同時這也是這篇論文被其他核心工作所引用的主要工作
UMON
UMON的全稱是utility monitor, 實現(xiàn)了對系統(tǒng)資源信息監(jiān)控的功能, 其具體電路的實現(xiàn)獨立于共享cache之外, 這樣做可以使UMON監(jiān)控cache中所有的way的實時信息, 而其后的劃分算法也正是利用其獲取的信息進行劃分,
[./pic/ucp1.png]
UMON所要追蹤的實時信息之一就是cache中所有way的命中情況, 舉個例子, 對于16路的cache來說, monitor一般要對16種不同的情況進行跟蹤, 從一個way到16個way, 這種情況雖然最簡單, 但代價卻相當?shù)馗? 實際上也不具備可行性, 因為這樣做需要設置16組tag directory, 并且每一組要有與cache相同的set數(shù), 所以硬件開銷十分巨大, 所以這篇論文利用了LRU算法的一個stack property, 就是一旦在LRU算法管理下N路cache命中, 在超過N way時也同樣會命中, 這使得在16路cache中只需要包含一組16way的tag directory即可.
[pic/ucp2.png]
如圖, 在每個set中都有4個位置, 每個位置代表一個way, 其中每個位置都會設置一個hit counter, 用來記錄在這個位置的cache命中情況, 比如說, 在第一個位置訪問cache命中, 與其對應的計數(shù)器就會加一, 也就能通過這些計數(shù)器得出所有位置的命中情況, 進而計算出總的命中率, 而在圖b中就顯示了LRU的stack property, 如圖所示, 當進行100次對cache的訪問, 四個位置的命中次數(shù)分別為30,20,15,10, 也就是說總的命中率為25%, 這也間接反映出cache訪問的一個局部性, 位置越靠前訪問的頻率越高, 而如果我們將4個cache way減少到3個, 命中率也就變成了65%, 以此類推。
UMON使用了ATD(Auxiiary tag directory)和hit counter來對整個cache信息進行跟蹤, ATD與cache有著相同的相聯(lián)度, 并且使用LRU作為總的替換策略, 一般來說, 在所有的set中都會有額外的tag directory, 并且都有hit counter, 但由于開銷過大, 這里就只使用一組hit count對多個set進行跟蹤, 但由于hit directory的原因, 這種方式的硬件開銷依然不小, 所以這篇文章使用了切比雪夫算法, 估計了在所使用的數(shù)據(jù)減小到多少的時候, 準確度依然及其接近使用全部tag directory的情況, 而這個做法也使硬件開銷變得真正可以接受.
[pic/ucp3.png]
algorithm
這篇文章的另外一個重要的部分就是其劃分算法, 這也是整個way-partition領域最核心的部分, 雖然這個算法比較老舊, 也在后續(xù)的論文成果中被不斷改進, 也不能磨滅其奠基的地位。
首先給出一個簡單而又基本的劃分策略
[此處有公式]
對于這個劃分, 其中只涉及兩個應用, UA與UB分別代表這兩個應用的具體性能, 此處性能可以用命中率表示, 同時也可以使用IPC(instruction per cycle), 此處, 每個應用至少會分到一個cache way, 并且在每5 million調(diào)用一次劃分算法, 用來找到對于所有應用性能最好的組合。乍一看算法本身合乎情理, 但卻存在一個十分嚴重的問題, 這個算法的應用環(huán)境是兩個core的, 而在實際應用場景下, 則可能遠多于兩個core, 而此時如果還依然按照窮舉的方法列舉出所有的劃分, 再逐一的對比性能, 則成了一個不可能完成的任務, 舉個例子, 在32way，8 core的環(huán)境下, 需要全部上千萬次的劃分, 此時開銷是無法接受的, 而實際上這是一個NP-hard問題。為解決這個問題, 這篇文章提出了一個貪婪算法, 該算法會逐一分配cache way到所有的應用中, 在每一次分配時, 跟蹤所有應用的性能變化, 找到那個能夠影響性能最大的應用, 并將這個cache way分配給它, 以達到性能最大化。
多數(shù)情況, 上述算法已經(jīng)是一種最優(yōu)的情況, 但其本身卻還是存在一個問題, 而這篇文章的重點也正是在不斷發(fā)現(xiàn)問題中解決問題的, 就是貪婪算法本身的問題, 它只能對每一個cache way的性能變化進行預測, 而不能對總的情況有一個合理的把握, 導致最后的untility 曲線是非凸的(non-convex), 見下圖, 前8個cache way的性能變化導致它永遠不能得到資源分配, 這也就導致劃分算法的性能不理想。
[pic/ucp4.png]
為了解決上面的問題, 這篇文章提出了最后一個劃分算法, lookahead算法, 顧名思義, 在劃分的同時也照顧到了之前的分配情況, 在討論具體的算法之前, 先給出一個指標MU
[此處為MU公式]
MU可以表示在分配多個cache way時的命中率改變, 而不只是一個cache way, 而在實際的算法中, 也是首先對所有的應用逐一分配所有的cache way, 選出其中對命中率提升最大的進行分配, 以此類推, 這么做不僅可以避免非凸的問題, 也可以將總的時間復雜度降到N^2/2
[pic/ucp5.png]
?lammps
上午編寫問題20min
下午發(fā)過去
?轉(zhuǎn) MD的格式要求
由于要把放到簡書上, 所以需要把org的文檔轉(zhuǎn)到md格式
1. 屬性信息不保留
2. 每段話盡量保證3-4行
3. 表格不保留, 但需要其他進行替換
org-mode
圖片問題
* latex
使用的模板由于各種原因出現(xiàn)無法使用的問題, 需要在23號之前進行解決
這里進行問題跟蹤與任務劃分
21:
- 找出傳統(tǒng)可以正常使用中文的方法
? 見latex網(wǎng)站, 使用的是xeCJK的方法, 而原來也同樣是采用的是xeCJK的方法
- 找出如何下載包
? tllocalmgr, install, texhash
- 找出本機有什么字體可用
? 在latex網(wǎng)站中, 本機可能的已經(jīng)將原本windows的字體載入了進來, 這里未進行驗證, 已經(jīng)驗證, 但系統(tǒng)級是否可以使用未知
? 使用fc-list :lang=zh, 可以看出win字體已經(jīng)安裝
--- 接下來要做的就是查看模板中的字體與本機已安裝的字體是否不匹配, package是否有未安裝的
*兩個公式待整理*
TODO
1. ss
Timetable
1855-2155: 3h
1855-2100: 2000字ucp
1915-2000: umon
2000-2100: algorithm
2100-2120: latex
2120-2140: lammps
2140-2155: 整理+發(fā)布
