# 台大 105 硬體
###### tags: `NTU` `105` `硬體`
1.
(a) 請搜尋: GPGPU
(b) supercomputer
\(c\) $\frac{8}{250}$
(d) 大部份的人並不需要可以在一秒內處理 2800 張影像的超級電腦
(e) 同層的節點運算是獨立的，GPU 強大的 SIMD 運算能力很適合這種場景
(f) Data fetch => input layer => hidden layer 1 => hidden layer 2 => hidden layer 3 => output layer => write data
(g) throughput up, latency up
(h) yes, TPU 就是一個例子
好處: 可以針對需求研發，徹底榨出所有性能
壞處: 彈性不夠大，需求改變時得砍掉重練; 成本太高
(i) 每個節點都得傳到另外 $\frac{N}{2}$ 個節點，所需傳輸量為 $\frac{N^2}{2}$
(j) $\frac{10A}{5A + 12.8QN}$
:::info
假設浮點數大小為 4 bytes。
5N 個點分配到 Q 個處理器上，每個點需要 A ns，總共為 $\frac{5AN}{Q}$
5N 個點分配到 2Q 個處理器上，總共為 $\frac{5AN}{2Q}$
傳輸時間需要 $\frac{N^2}{2}\times 32(bits)\div 10(Gbps)$ ns，因為總共有五層，所以要傳四次
speed up: $\frac{10A}{5A + 12.8QN}$
:::
(k) $\frac{5A}{12.8QN}$
:::info
P 台電腦，傳輸時間需要 $\frac{(P-1)N^2}{P}\times 32\times 4\div 10 = 12.8N^2$ ns
:::
(l)
- small: 用 GPU 就可以了
- medium: 用 PX2，或是 FPGA
- large: 用複數台 PX2、FPGA，或是客製化晶片
2.
(a) yes
:::info
以下考慮最壞的情況
read: 讀取 invalidate queue，發現資料已經被別的 CPU 修改 -> 讀取記憶體 -> page fault -> 執行 LRU 找出該被淘汰的 block -> 放進去
write: 發送 invalidate message -> 寫進 cache / 記憶體
:::
(b) no
:::info
假設題目的意思是有某個變數被某個 CPU 寫入，然後被另外一個 CPU 讀取，這樣來回交替。接著再存取同個 block 的其它資料。

如果是這樣的話，因為兩邊都有最新的資料，所以不會發生 false sharing
:::
\(c\) NO
:::info
ABI 是二進位介面，是二進位檔與機器互動的介面，參考: [ABI](https://en.wikipedia.org/wiki/Application_binary_interface)
:::
(d) NO, 都是 API
(e) NO, JVM 是為了讓 APP 不用針對每種裝置重新編譯，而不是作業系統本身

3. 先搞清楚每種 request 的意義
- local read: 讀取自己的 cache
- remote read: 別的 CPU 來要資料
- local write: 寫自己的 cache
- remote write: 別的 CPU 來要資料，要回去後寫入

| | Invalidate |Shared |Exclusive |
|- |:---------- |:------ |:--------- |
|**local read**|Shared|Shared|Exclusive|
|**remote read**|Invalidate|Shared|Shared|
|**local write**|Exclusive|Exclusive|Exclusive|
|**remote write**|Invalidate|Invalidate|Invalidate|

false sharing 可藉由把兩個變數隔開來避免，假設 block size 為 16 bytes:

struct {
    int a;
    char padding[12];
    int b;
}

這樣就可以確保 a 跟 b 不會在同個 block
4. (a) YES (b) YES
5. 連線到一半突然斷線、伺服器與本地裝置時間不一致等等...
6.
(a) Buffered / Unbuffered I/O: 將 I/O 資料 暫存/不存 在 user space 裡 | Buffered I/O 只需一次 copy，Unbuffered I/O 需要多次 copy
(b)
i. random access 應該會比較好...
ii. [這裡](https://medium.com/@clu1022/%E6%B7%BA%E8%AB%87i-o-model-32da09c619e6)寫得很清楚
7. 當 request 太多時 thread 會不夠用
8.

// 將 semaphore 加一，並隨機喚醒一個 process
signal(semaphore *);
// 將 semaphore 減一，如果小於零就 sleep
wait(semaphore *);

typedef struct {
    semaphore mutex(1);
    int count;
    semaphore wait(0);
} barrier;

void barrier_wait(barrier *b, int n) {
    wait(&b->mutex);
    b->count++;
    signal(&b->mutex);
    if (b->count < n) {
        wait(&b->wait);
    }
    signal(&b->wait);
}

(b) prority-based scheduling / 用一個 table 記錄每個 friend 對每個檔案的存取優先權
9. 跟 8(b) 一樣的方法...隨便啦