假设我有 100 个文本文件
file_0.txt
file_1.txt
.
.
.
file_99.txt
我想尽快阅读它们。我是一名软件开发人员，在硬件方面没有很好的背景。所以我想知道“最大并行度”是否是我的 CPU 数量？如果我有 4 个 CPU，那么我应该尝试并行读取 4 个文件，还是它们会以 ~1/4 的速度读取并且对性能没有帮助？
如果我需要发出 100 个 Web 请求并得到他们的响应，该怎么办？有多少硬件端口事物可以等待响应？
如何预测要使用的并行度？
问问题
593 次
1 回答
3
好吧，这远远不是一个真正的[PARALLEL]过程（调度），即使你的教授或想成为“书呆子”的人试图这样称呼它。
没有办法让 100 辆汽车并排驶过一座只有一条纯车道的桥。[PARALLEL]
[SERIAL]
如上所述，fileIO 是一个“公正”的[CONCURRENT]进程，没有这样的设备（无论是旋转磁盘，还是任何形式的 NAND/FLASH-SSD 磁盘仿真设备），可以从100 个不同的文件位置在同一时间。
最大的期望是隐藏进程流的非 CPU 部分的某些部分（缓冲区和控制器缓存重新排序的 fileIO 可能会掩盖主体的某些部分~10 [ms]寻道时间（不超过每秒 125 次寻道，即使在 RAID 上）和数据流永远不会超过〜250 [MB/s/disk]在经典的旋转磁盘上，网络传输延迟 + 远程进程处理在 web 请求的情况下总是会累积〜从单位到小数百个，[ms]仅用于 L3-TCP /IP-RTT-latency + 添加任何远程处理所需的内容）。
如果进入高性能领域，肯定要对硬件有正确的理解，因为所有软件高级构造函数都希望用户了解利弊（并且在大多数情况下，不要放弃所有与硬件相关的决策对用户而言，因此在大多数情况下，应该针对各自的硬件平台进行基准测试以识别/验证，如果这些各自的软件构造器确实对过程性能产生了任何有益的影响，或者没有——比接收更多的损失是一个非常如果盲目相信或幼稚的实现确实得到了基准测试，那么这个领域的普遍惊喜）。
问：如何预测要使用的并行度？
A：
一种分析方法——识别游戏中最窄的桥：
深入到将部署代码的真实系统硬件基础设施，以便识别计算图中最薄弱的处理链元素（非常桥，具有最少数量的真正并行通道 - fileIO 有 ~ 1 通道，4 核 CPU 有 ~ 4 通道（可能有超过 8 通道，如果每个 CPU 核心有 2-ALU 并且只做一些做得好的局部保留重型数字运算），具有〜2通道的2通道DRAM等）
一种实验方法——测量所有可能组合的性能：
如果不愿意花费这些努力，或者如果这些信息没有足够详细的水平用于分析方法，则可以准备并运行一组盲目的蛮力黑——盒基准测试，测量受控并发水平/本地部署的细粒度并行技巧的体内性能影响。实验数据可能表明方向，可能会对最终的端到端过程性能产生有益或不利的影响。
已知限制：
没有可重复的受控实验，如果超出localhost（局域网/广域网背景流量工作负载信封、远程防火墙、远程处理节点、任何中介设备上的虚假间歇工作负载——所有这些都只是阻止了实验本身的可重复性，如果结果旨在与最终决策有一定的相关性（10x、100x、1000x 不是衡量标准，如果迫切需要涵盖各种背景工作负载影响每个实验设置组合的性能评估））。还可能需要检查远程网站的条款和条件，因为许多 API 提供商实施日常使用限制/费率调整政策，以免因违反这些条款而进入各自的黑名单/永久禁令和
完整视图和技术纯粹主义者的结语：
是的，确实有针对高级、HPC 级、处理性能的策略，可以绕过这个主要瓶颈，但不太可能在常见的 HPC 并行文件系统上实现凡人的用户土地，因为超级计算资源属于资金充足的联邦/欧盟/政府资助的研发或军事/政府机构，它们运行这种对 HPC 友好的环境
于 2017-12-22T08:10:33.270 回答