并行分配（）在某些设备上很慢大家好你们好，
并行分配（）与某些系统结合使用似乎存在问题。
我可以使用 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() 时仍然应该避免使用函数。
干杯
抢
