mirror of
https://github.com/gopl-zh/gopl-zh.github.com.git
synced 2025-08-06 07:32:07 +00:00
zz
This commit is contained in:
@@ -27,7 +27,7 @@ func makeThumbnails(filenames []string) {
|
||||
|
||||
顯然我們處理文件的順序無關緊要,因爲每一個圖片的拉伸操作和其它圖片的處理操作都是彼此獨立的。像這種子問題都是完全彼此獨立的問題被叫做易併行問題(譯註:embarrassingly parallel,直譯的話更像是尷尬併行)。易併行問題是最容易被實現成併行的一類問題(廢話),併且是最能夠享受併發帶來的好處,能夠隨着併行的規模線性地擴展。
|
||||
|
||||
下面讓我們併行地執行這些操作,從而將文件IO的延遲隱藏掉,併用上多覈cpu的計算能力來拉伸圖像。我們的第一個併發程序隻是使用了一個go關鍵字。這里我們先忽略掉錯誤,之後再進行處理。
|
||||
下面讓我們併行地執行這些操作,從而將文件IO的延遲隱藏掉,併用上多核cpu的計算能力來拉伸圖像。我們的第一個併發程序隻是使用了一個go關鍵字。這里我們先忽略掉錯誤,之後再進行處理。
|
||||
|
||||
```go
|
||||
// NOTE: incorrect!
|
||||
@@ -186,4 +186,4 @@ sizes channel攜帶了每一個文件的大小到main goroutine,在main gorout
|
||||
|
||||
練習8.4: 脩改reverb2服務器,在每一個連接中使用sync.WaitGroup來計數活躍的echo goroutine。當計數減爲零時,關閉TCP連接的寫入,像練習8.3中一樣。驗證一下你的脩改版netcat3客戶端會一直等待所有的併發“喊叫”完成,卽使是在標準輸入流已經關閉的情況下。
|
||||
|
||||
練習8.5: 使用一個已有的CPU綁定的順序程序,比如在3.3節中我們寫的Mandelbrot程序或者3.2節中的3-D surface計算程序,併將他們的主循環改爲併發形式,使用channel來進行通信。在多覈計算機上這個程序得到了多少速度上的改進?使用多少個goroutine是最合適的呢?
|
||||
練習8.5: 使用一個已有的CPU綁定的順序程序,比如在3.3節中我們寫的Mandelbrot程序或者3.2節中的3-D surface計算程序,併將他們的主循環改爲併發形式,使用channel來進行通信。在多核計算機上這個程序得到了多少速度上的改進?使用多少個goroutine是最合適的呢?
|
||||
|
Reference in New Issue
Block a user