當優化擴充套件到多核時

2022-02-22 18:52:32 字數 1514 閱讀 3256

"軟體開發沒有銀彈,我們能做的就是選擇和平衡;"首先,我們需要確定,我們的單個任務是否可以分解;比如解析很多個檔案,這樣的任務劃分成多個很簡單;但如果是乙個耗時的序列邏輯計算,後期的計算依賴前期的結果,這樣就不好拆分;這種形式可能需要在更高層次上來拆分;

程式設計就是計算和資料;計算並行了,但資料還是訪問同乙份,訪問共同的資源會產生資源競爭;

如果不進行控制,可能導致同乙份資料重複計算(多個讀的場景)或是髒資料的產生(有回寫的場景);

為了讓資料訪問有序進行,需要引入鎖來防止髒資料;

控制鎖的粒度,是個需要精心考慮的話題;

比如對於大量讀少量寫的場景,相比一視同仁的加鎖,使用讀寫鎖能顯著提公升效率;

我們日常能接觸到的產品中,資料庫是個用鎖高手,在更新資料的時候,是鎖住行,還是列、或是表,不同的粒度效能相差明顯;

考慮這樣的場景:多個執行緒都在等在乙個鎖,如果可以拿到鎖,執行緒就開始工作(執行緒池)

當鎖被釋放時,如果喚醒多個執行緒可能會產生 驚群現象;

解決方案:

使用單執行緒方案/處理accpet連線 處理等待鎖的操作,讓任何時刻只有乙個執行緒在等待鎖;

更多細節參考:

《客戶-伺服器程式設計方法》中 預先建立執行緒池,每個執行緒各自accept 一節

讓每個執行緒使用自己的資料,讓資料不共有,這樣能去掉資源競爭,去掉鎖;

將資料複製為多份,減少競爭,各自訪問各自的資料;

但這又引入了乙個新的問題:如果各個執行緒回寫了資料,如何保證這麼資料的一致性?

畢竟它們代表的其實是乙份資料;

涉及到資料的一致性,多份資料之間的同步又是個難題;

那好,換個思路,不使用資料複製;我們使用資料分片;分片這個思想更容易想到,既然「計算」被劃分為多個小任務了,那麼資料也可以同樣處理;

將資料分片,每份資料存的內容不相同,它們之間沒有共同點;

這樣,資料訪問沒有資料競爭,同時由於資料不同,也不涉及到資料一致性同步的問題;

但,分片遠遠沒有想的那麼美好;

分片導致了每個執行緒看到資料不再是全集,而是片段;這就注定了這個執行緒只能處理這部分的特定資料;這樣,執行緒之間的計算失去了可替換性;某種工作只能在特定的執行緒上處理;

而如果有個任務需要訪問所有的資料,這樣就變得更加複雜;

原來,分片之後,我們將難題向上推了,推到執行緒層面,需要考慮到業務邏輯層面的處理;

這樣,可能更加複雜;

ok,想要速度更快,使用多核來處理,需要面對更多的問題;

將單機擴充套件多機集群,涉及到架構層面來看,其實我們的面對的問題是類似的;

參考:《大型**技術架構》讀書筆記[2] - 架構的模式

軟體開發沒有銀彈,我們能做的就是選擇和平衡;

posted by: 大cc | 13aug,2015

部落格:blog.me115.com [訂閱]

github:大cc

當優化擴充套件到多核時

軟體開發沒有銀彈,我們能做的就是選擇和平衡 首先,我們需要確定,我們的單個任務是否可以分解 比如解析很多個檔案,這樣的任務劃分成多個很簡單 但如果是乙個耗時的序列邏輯計算,後期的計算依賴前期的結果,這樣就不好拆分 這種形式可能需要在更高層次上來拆分 程式設計就是計算和資料 計算並行了,但資料還是訪問...

當優化擴充套件到多核時

軟體開發沒有銀彈,我們能做的就是選擇和平衡 首先,我們需要確定,我們的單個任務是否可以分解 比如解析很多個檔案,這樣的任務劃分成多個很簡單 但如果是乙個耗時的序列邏輯計算,後期的計算依賴前期的結果,這樣就不好拆分 這種形式可能需要在更高層次上來拆分 程式設計就是計算和資料 計算並行了,但資料還是訪問...

演算法作業 八皇后問題擴充套件到N皇后

問題背景 在 8 8 格的西洋棋上擺放八個皇后,使其不能互相攻擊,即任意兩個皇后都不能處於同一行 同一列或同一斜線上,輸出所有擺法。環境 vs2017 include pch.h include include include using namespace std const int max si...