並行分配（）在某些設備上很慢大家好你們好，
並行分配（）與某些系統結合使用似乎有問題。
我可以使用 JMP 16.1 存取 3 台 Windows 10 電腦：
- 筆記型電腦：Core i5-8350U（4 核心）@ 1.9 GHz，16GB RAM
- 舊工作站：Xeon E5-1660 v4（8 核心）@ 3.2 GHz，256GB RAM
- 全新工作站 Xeon W-2145（8 核心）@3.7 GHz，128GB RAM
我在所有系統上使用不同的問題大小比較了測試腳本的平行版本和順序版本的效能（下面的腳本）。
結果出奇的糟糕。 僅在我的筆記型電腦上，並行版本比順序版本稍快，但在工作站上慢了 2 倍以上。
有人在使用並行分配（）時遇到類似的效能問題嗎？ 還是我用錯了？ 這裡發生了什麼事？
搶
n_different_ids = 100000;
<BR />// Just generate random data. Every 15 rows must be processed at the same time.
DT_Data = J( 15*n_different_ids, 9, 0 );
For ( i = 1, i <= n_different_ids, i++,
DT_Data[15*(i-1)+(1::15),0] = i + J( 15, 9, Random Normal() );
);
<BR />// some function
F_percentile = Function( {x , p},
x = Sort Ascending(x);
n = N Rows(x);
index = 1 + (n - 1) * p;
index_ibelow = Floor(index);
index_iabove = Ceiling(index);
h = index - index_ibelow;
result = (1 - h) * x[index_ibelow] + h * x[index_iabove];
result;
);
<BR />// parallel version
DT_Features = J( n_different_ids, 16, 0 );
start=tick seconds();
Parallel Assign( {
DT_Data = DT_Data,
F_percentile = Name Expr( F_percentile )
},
DT_Features[i,j] = (
i_same_group = Loc(DT_Data[15*(i-1)+(1::15), 1]);
data = DT_Data[15*(i-1)+i_same_group, 1+Ceiling(j/2)];
If (mod(j,2),
result = F_percentile(data, 0.95);
,
result = F_percentile(data, 0.05);
);
result;
)
);
time_parallel = tick seconds()-start;
Show(time_parallel);
Wait(0.1);
<BR />// sequential version
DT_Features = J( n_different_ids, 16, 0 );
start=tick seconds();
for(i=1,i<=n_different_ids,i++,
for(j=1,j<=16,j++,
i_same_group = Loc(DT_Data[15*(i-1)+(1::15), 1]);
data = DT_Data[15*(i-1)+i_same_group, 1+Ceiling(j/2)];
If (mod(j,2),
result = F_percentile(data, 0.95);
,
result = F_percentile(data, 0.05);
);
DT_Features[i,j] =result;
);
);
time_sequential = tick seconds()-start;
Show(time_sequential);
進階統計建模自動化和腳本編寫資料存取數據探索和視覺化大規模客製化品質和工藝工程分享和交流成果回覆：並行分配（）在某些設備上速度很慢你好@ih ,
同意。
對我來說，設定一個孩子的開銷並不重要，所以我沒有花太多時間來使其盡可能有效。 該腳本並不意味著只運行幾分鐘。 在開始這個主題之前，我完全按照您的建議做了。 我將資料集分成 8 個部分，並在 0.5 天內完成。 出於興趣，我後來也嘗試了 Evan 的「Sequential_Expr_Opt」版本，花了 1.5 到 4 天的時間來完成我的資料集（週四早上開始，週五下午但週一早上沒有完成）。
這條線索是為了顯示幕後整體上存在一些問題。 過去，我時不時地註意到 JMP 的並行性能很差，這讓我很困擾。 我喜歡 JMP，並且喜歡用它來嘗試其他人認為用 JMP 無法完成的事情。 我非常高興開發人員正在研究它。
但我必須說，有比 JMP 更好的工具來處理大型資料集。 至少目前是這樣。 
回覆：並行分配（）在某些設備上速度很慢你好@羅布，兩個想法：
程式設計速度
程式碼的目標會對您的編寫方式產生很大影響。對於絕大多數腳本來說，呼叫函數或複製符號所需的額外時間並不重要，所以是的，您應該使用函數並使程式碼易於解釋。另一方面，如果您正在處理一個大型項目，並且重複次數足夠多，以至於您關心它需要多長時間，那麼您可能想開始用一些細節來換取原始效能。我鼓勵您只花時間優化真正重要的事情。不要現在花額外的一個小時編碼一些東西，然後又不得不花額外的一個小時來弄清楚一年後你做了什麼，因為你為了加快速度而讓它變得更加複雜，只是為了每天為用戶節省一次額外的20 秒。
平行權衡
在決定是否並行執行時，您需要平衡設定「子」執行緒的開銷及其將要執行的工作。想像一下，您要透過開啟 JMP 的另一個副本、開啟資料表並按一下執行來執行平行作業。 如果讓它運行一個小時那就太好了，與只讓一個腳本完成所有操作相比，您將節省大量時間，但如果該腳本要運行20 秒，那麼您可能會花費更多時間啟動它然後保存。是的，這裡的開銷要小得多，但是複製符號和分配記憶體確實需要時間。確保環境設定後您的腳本將完成大量工作。實現這一目標的一種方法是將循環分成 4 個部分，並讓每個執行緒同時處理四分之一的值。因此，將清單分成四個部分，每個部分有四分之一的行，然後讓腳本按順序處理每個子清單。 這樣您就可以將設定子執行緒所花費的時間從 n row() 次減少到 4 次。
回覆：並行分配（）在某些設備上速度很慢我聽從了克雷吉斯的建議，兩週前聯繫了技術支援。 在對我的電腦進行一些詢問後，我今天得到了答复，開發人員已參與調查該行為並修復未來 JMP 版本中的問題。
儘管如此，再次感謝埃文加快了這個特定腳本的速度。
回覆：並行分配（）在某些設備上速度很慢哦，哇，謝謝！ 在我的新工作站上運行你的腳本我得到
並行：37.0833333333139
順序：19.7166666666453
平行_表達式：6.93333333331975
順序表達式：12.5333333333256
順序_表達式_選項：4.54999999998836
我們不要考慮 Sequential_Expr_Opt ，因為這是一個不公平的比較。 
您只需用表達式取代該函數，順序版本的加速約為 1.5，並行版本的加速超過 5（！！！）？ 這是一個很好的解決方法。 那我能從中學到什麼呢？ 從未使用過 JSL 中的函數？ 這有點令人不快，因為函數使程式碼更具可讀性，並且更容易、更安全地為其他人使用和修改。 然而，我認為幕後仍然存在問題，因為我最初的平行版本仍然需要原始串行版本的兩倍時間，而 Craige 的虛擬機器上的情況並非如此。
更新：這是新工作站的完整掃描：
回覆：並行分配（）在某些設備上速度很慢對於我的 3.6GHz 4 核心機器，N=100k：
使用平行程式碼比順序程式碼獲得了 1.4 倍的加速（12.8 秒並行 vs 17.8 秒順序）。 這不如 Craige 看到的 2.7 倍加速，但比您在工作站上看到的減速行為要好。 然而，我想看看是否可以從中獲得更多的性能，所以我做了一些編輯。
我透過使用表達式來消除函數呼叫開銷（矩陣參數副本等）。 這使我的速度提高了 2.5 倍（並行 4.5 秒，順序 11.3 秒），並且比原來的速度快了很多。 最後，我嘗試稍微重新安排循環，並將順序版本降低到 4 秒。 這比並行版本更快，但使用並行分配重新排列並不那麼容易。 我測試了一些不同的 N，這些模式似乎成立，但我沒有像上表中那樣進行全面掃描。 找到附加的代碼。
平行：12.78
順序：17.80
並行_Expr：4.50
順序表達式：11.27
順序表達式選項：3.98
回覆：並行分配（）在某些設備上速度很慢我還將新工作站上 JMP 可用的任務管理器核心數量限制為 2 個、4 個和 8 個。 並行版本仍然比串行版本慢。 我的猜測是，JMP 在後台使用過時的庫，這些庫在新的硬體架構上運作不佳。
謝謝克雷格，我將聯絡技術支援。
回覆：並行分配（）在某些設備上速度很慢沒有把握。 我向 JMP 發送了有關此主題的註釋；您可能還想與技術支援聯繫。
我的猜測（僅此而已！）是 JMP 需要進行一些更改才能恢復新硬體的效能。 只有 4 個虛擬 CPU，我看不到你看到的相同的東西。
回覆：並行分配（）在某些設備上速度很慢我可以在我的筆記型電腦（Win 10、JMP 16.1）上確認該行為：
時間並行 = 158.7;
時間順序 = 157.766666666667;
n=1000000
回覆：並行分配（）在某些設備上速度很慢嗨克雷格，
我現在正在查看性能最差的工作站（如下）。 我在任務管理器中沒有看到任何可疑的東西。 除了CPU之外，沒有任何東西接近完全佔用。
我還注意到 JMP 15.2.1 在並行和順序版本中總是更快。 在 n=100,000 的情況下，JMP 16.1 大約需要 36 秒/18 秒（並行/順序），JMP 15.2.1 需要 31 秒/15 秒，稍好一些，但距離良好的並行性能還很遠。 不幸的是，我不再有舊版本可用。 我使用 JMP 12 編寫了這段程式碼，當時沒有註意到效能問題（而且我使用的 PC 也不同）。
搶
回覆：並行分配（）在某些設備上速度很慢這是 VirtualBox 下的 4-CPU 16GB ~3GHz 機器 JMP16/win10。 我看到了預期的速度提升（不是 4 倍，但仍然不錯。）
n_不同_id = 100,000；
時間並行 = 13.9833333333333;
時間順序 = 37.7333333333333;
n_ different_ids = 1,000,000;
時間並行 = 141.233333333333;
時間順序 = 375.016666666667;
並行分配正在為每個 CPU 複製一個大矩陣，但線性圖並不表示在這些大小下這是一個分頁問題。
觀察 Windows 任務監視器的 CPU 和記憶體（和磁碟）使用情況，看看它是否能解釋什麼。 我在並行分配期間看到了 100%，在順序測試期間看到了 25%。 我還看到在更大的並行分配期間使用了 7GB。
task managertask managertask managertask manager工作管理員
回覆：在某些裝置上，並行賦值() 函數速度較慢大家好，
好消息！時隔三年，我再次運行了全部五個並行基準測試（再次感謝@EvanMcCorkle ），這次使用的是我當時已有的電腦，並且使用的是 JMP 19.0.4 版本。與 JMP 16 相比，使用表達式時並行效能有了顯著提升。 JMP 19 的速度大約提升了 5 倍，這與兩個 JMP 版本在「Sequential_Expr_Opt」基準測試中的表現類似。儘管效能有所提升，但在使用 Parallel Assign() 時仍應避免使用函數。
乾杯
搶
