我試圖理解並行分配以嘗試加速一些小操作。我運行以下腳本（警告它耗盡了我的內存並將我鎖定），我發現它隨著向量中的行數呈指數級減慢。
for(i=1, i<=5, i++,
t = [59760, 71220, 79380, 83820, 3300, 11400, 27900, 39060, 43500, 51300,56220, 60];
t = repeat(t, 10^i);
n = nitems(t);
diff = t[2::n]-t[1::(n-1)];
day_v = diff < 0;
st = HPTime();
day_cum = cumulative Sum([0]|/day_v);
tot_cum = HPTIme() - st;
st= HPTime();
day_break = loc(day_v); // this will give you last row of the day
// make a matrix n x number of day breaks
m = J(n, nitems(day_break), -1);
parallel assign({db = day_break},
// make the item a 1 if it's row is higher than the corresponding row
m[a, b] = a > db[b];
);
m;
// now just sum the matrix
day = VSum(m`); // +1; // if you want the day to start at 1
tot_pa = HPTime() - st;
show(n, tot_pa, tot_cum);
);
我不希望並行分配比cumulativesum() 更快，但我很好奇並行分配是如何工作的。
我讀了這我猜這是因為它為每個線程創建非常大的矩陣的副本？
有誰對它如何運作有任何其他見解，也許還有一些並行分配的基本注意事項？
好點，我沒有想到我的例子不是同類比較。謝謝@Craige_Hales ，這個確實很有用。
並行分配做得非常出色！ 我認為數組 m 的大小是實際問題：它正在突飛猛進地增長，或者每次迭代增長 100 倍。
| 我 | 尼特姆(米) | Seconds_in_Parallel_Assign | Seconds_in_Nested_Loops |
| 1 | 2,400 | 對於 tikseconds() 來說太小 | .18 |
| 2 | 240,000 | .033 | 19 |
| 3 | 24,000,000 | 3.3 | 1951年 |
| 4 | 2,400,000,000 | 第338章 | 放棄了等待 |
那個劇本，
m[a, b] = a > db[b];
每秒執行約 700 萬次（4-CPU 17.5G VirtualBox）。 我的內存也用完了，這意味著尋呼。 分頁會導致速度急劇下降，也許在 i==5 時。
第 4 列（嵌套循環比較）的製作方式如下（屏幕截圖...計算機正忙於嘗試達到第 3 行的 1900 秒）：
這是並行分配問題的設計目的。 部分速度來自 C++ 循環而不是 JSL 循環，部分來自線程。
