FTRL演算法效能優化

2021-07-25 15:57:04 字數 1453 閱讀 9112

原演算法(worker端):

1. 對1個mini-batch, 得到每個sample的非0特徵值的feature-id,排序(ps-lite要求key必須有序),去重

2. 以這組feature-id為key, 從server上pull,得到對應的weights

3. 對每個sample[i], 對其所有非0特徵值的feature-id對應的weight, 進行加和,得到sum_w[i]

4. 對每個sample[i]的sum_w[i],得到梯度delta[i] = sigmoid(sum_w[i]) - label[i]

5. 對每個sample[i], 掃瞄其所有feature-id, 設其對應的weight為weight[k],累加gradient[k] += delta[i]

6. 把所有gradient[k],push給server, 去更新weights

原實現:

3. 使用feature-id --> weight的map(unordered_map) ,即下面的weight[idx]

5. 使用feature-->gradient的map(unordered_map), 即下面的gradient[idx]

缺點:乙個batch大小1000,每個sample個數平均2000, 1000*2000*8byte=16mb, 在cache中放不下,頻繁訪問記憶體,造成速度慢;

原實現**:

for(int row = start; row < end; ++row)

pctr = sigmoid(wx);

float delta = pctr - train_data->label[row];

for(int j = 0; j < keys_size; j++)

}

優化實現:

1. 把所有sample的所有key, 放到struct陣列裡,struct欄位:

2. 把struct陣列(名字為sortedks)按key從小到大排序

3. 把key單獨放在乙個陣列(名字為keys)裡,向server去pull weights, 得到weights陣列

4. 對sortedks和keys進行類歸併掃瞄操作,匹配中的,找到struct對應的sample-id,更新對應的weight:

sum_w[sortedks[soredks_id].sample-id] += weights[keys_id]

5. 迴圈sum_w(長度為sample個數),  得到梯度delta[i] = sigmoid(

sum_w[i]) - label[i]

6. 同步驟4,再次類歸併掃瞄,匹配中的,累加對應的gradient: 

gradient[keys_id] += delta[sortedks[soredks_id].sample-id]

優點:無hash表;順序掃瞄陣列;sum_w和gradient只有幾kb, 可以放入cache

React Diff 演算法及效能優化

setstate是非同步操作,多次setstate合併成一次setstate,減少 diff 比對 兩個虛擬 dom 進行比對時,從上往下進行比對,如果同一層比對存在差異時就不會繼續進行比對 引入 key 值提高比對效能,其中 key 值最好不要為 index,應該是固定 唯一的值,比如 item ...

mysql效能優化 mysql效能優化

優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下,存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢,hash有利於精確查詢。btree用的更多一些。btree索引的常...

效能優化 電量優化

使用battery historian來監測電量的情況,battery historian時google的乙個開源專案 具體安裝過程參見 當出現下列畫面,說明已經開啟 其開啟成功以後,訪問網頁如下所示 說明 這裡使用的是一台國外的vps伺服器,原本是想在本地虛擬機器實驗的,一直連線超時,就換成了vp...