我们说我有100个文本文件
file_0.txt
file_1.txt
.
.
.
file_99.txt
我希望尽快读取它们。我是一名软件开发人员，并且没有很好的硬件背景。所以我想知道＆＃34;最大程度的并行度和＃34;是我的CPU数量？如果我有4个CPU，那么我应该尝试并行读取4个文件，还是以1/4的速度读取速度并没有帮助提高性能？
如果我需要提出100个网络请求并获得他们的回复呢？有多少硬件端口东西可以等待响应？
如何预测使用的并行度？
答案 0 :(得分：3)
嗯，到目前为止，这不是真正的[PARALLEL]进程（日程安排）的情况，即使你的教授或想要 - ＃34;书呆子＆＃34;试着这样称呼它。
[PARALLEL]横过一座桥梁并排移动100辆汽车，这只有一条纯净的[SERIAL]车道在河上。 如上所述，fileIO是一个＆＃34;只是＆＃34; - [CONCURRENT]进程，没有这样的设备（无论是旋转磁盘，还是任何形式的NAND / FLASH-SSD磁盘 - 仿真设备），可以在同一时间从100个不同的文件位置读取并平滑地传送数据。
可以预期的最大值是隐藏进程流的非CPU部分（缓冲区和控制器缓存重新排序的文件IO可能会掩盖主体的某些部分〜 10 [ms] 搜索时间（即使在RAID上也不超过~125次搜索），并且在经典旋转磁盘，网络传输上数据流永远不会超过〜 250 [MB/s/disk] 在网络请求的情况下，延迟+远程流程处理将始终从单位累积到数百[ms] 仅适用于L3-TCP / IP- RTT-latency +添加远程处理所需的任何内容。
如果进入高性能领域，肯定必须对硬件有正确的理解，因为所有软件高级构造函数都希望用户理解缺点和优点（在大多数情况下，不要留下所有硬件与用户相关的决策，因此在大多数情况下，如果相应的软件构造函数确实对流程性能产生任何有益影响，则应该针对相应的硬件平台进行基准设置以识别/验证 - losing way more than receiving is a very common surprise in this domain, if a blind-belief or naive-implementation gets indeed benchmarked ）。
答
分析方法 - 识别游戏中最狭隘的桥梁：
深入了解将部署代码的实际系统硬件基础架构，以便识别计算图中最弱的处理链元素（非常桥，具有最少数量的真并行通道 - fileIO具有~1 -lane，具有~4通道的4核CPU（可能有超过8个通道，如果每个CPU核心具有2个ALU，并且只做一些做得好的局部保存的重数字运算），2通道DRAM具有~2车道等）
实验方法 - 测量所有可能组合的表现：
如果不愿意花费这些努力，或者如果没有足够详细的分析方法获得此类信息，可以准备并运行一组盲蛮黑箱基准测试实验，测量
控制水平的并发/局部部署的细粒度并行技巧的体内性能影响。实验数据可能表明方向，可能会对最终的端到端流程性能产生有利或不利的影响。
已知限制：
如果超出localhost（局域/广域网背景流量工作负载包络，远程防火墙，远程处理节点，虚假间歇性工作负载），则不存在可重复控制实验任何中介设备 - 所有这些只是阻止实验本身可重复，而不仅仅是一些非常大的经验性能测试DataSET中的一个样本，如果结果旨在具有一定的相关性最终决定（10x，100x，1000x不是衡量标准，如果严重需要涵盖各种背景工作负荷影响每个实验设置组合的性能评估））。也可能需要检查一个远程网站条款＆amp;条件，因为许多API供应商实施日常使用限制/费率调整政策，以便不会因违反这些条款和条款而进入各自的黑名单/永久禁令。条件。
Epilogue for complete view＆amp;技术纯粹主义者：是的，确实有先进的HPC等级处理性能的策略，可以规避这个主要的瓶颈，但是不太可能实现这样一种HPC并行关于普通人的文件系统＆＃39;用户登陆，因为超级计算资源属于资金充足的联邦/欧盟/政府赞助的R＆amp; D或mil / gov机构，它们运营这种HPC友好型环境