并发编程高性能计算【免费下载链接】oneTBBoneAPI Threading Building Blocks (oneTBB)项目地址https://gitcode.com/gh_mirrors/on/oneTBB点击查看免费下载本篇基于 oneTBB 官方用户指南中的Estimating Flow Graph Performance一节讲解如何在运行前估算 oneTBB flow graph 的性能上限与可扩展性首先用关键路径critical path推导出依赖型图的最大加速比然后结合 include/oneapi/tbb/flow_graph.h 与 include/oneapi/tbb/detail/_flow_graph_node_impl.h 的源码剖析节点 body 默认的任务化调度开销以及用lightweight策略将其内联消除的机制与前提条件。读完后你将掌握一套可操作的估算流程算出自己图形的加速比上限并判断哪些细粒度节点值得改用轻量策略。一、为什么 Flow Graph 性能难以直接预测oneTBB 的 flow graph 中所有执行都是异步的try_put在生成一个任务或把消息缓存之后立即返回控制流节点 body 任务执行完 lambda 后把结果发给后继节点只有wait_for_all会阻塞而且调用线程在等待期间还会参与执行 oneTBB 工作池中的其他任务见 doc/main/tbb_userguide/Mapping_Nodes2Tasks.rst。因此不能简单地用节点耗时 × 节点数来估算墙钟时间而需要抓住两个结构性因素依赖结构决定的并行上限哪些节点之间必须串行执行任务调度引入的额外开销每个节点 body 被包装成独立任务时付出的调度成本。官方文档将 flow graph 分为两大类见 doc/main/tbb_userguide/Graph_Main_Categories.rst数据流图Data flow graph数据沿边在节点间传递节点接收、变换并转发消息依赖图Dependence graph节点直接通过共享内存访问数据消息类型为continue_msg边只表达偏序依赖。依赖图中的continue_node会统计收到的消息数只有当数量等于前驱总数时才生成任务执行 body见 doc/main/tbb_userguide/Dependence_Graph.rst。下文两个估算要点分别对应这两个因素。二、关键路径决定了依赖图的扩展性上限2.1 形式化定义对于依赖图关键路径critical path是指从无前置节点的起点到无后继节点的终点之间耗时最长的路径。由于同一条路径上的节点存在严格顺序约束它们的执行无法重叠。据此可以推导出一个简洁的上界设T为所有节点若顺序执行所消耗的总时间设C为耗时最长的那条路径上的时间总和即使其余所有路径都与关键路径完全并行并行执行的墙钟时间也至少是C因此忽略微架构与内存效应后最大可能的加速比为T / C。这个公式给出了一个非常重要的实践含义在投入工程优化之前先画出依赖关系并找出关键路径。如果T/C本身很小那么无论线程加到多少、调度器多高效加速比都不可能突破这个上界优化重心应该转向缩短关键路径上节点的执行时间或者重排依赖关系。2.2 用一个真实示例验证oneTBB 文档中 doc/main/tbb_userguide/Dependence_Graph.rst 给出的经典示例做三明治依赖图就是一个可以直接套用该公式的依赖图typedef continue_node continue_msg node_t; typedef const continue_msg msg_t; int main() { oneapi::tbb::flow::graph g; node_t A(g, [](msg_t){ a(); } ); node_t B(g, [](msg_t){ b(); } ); node_t C(g, [](msg_t){ c(); } ); node_t D(g, [](msg_t){ d(); } ); node_t E(g, [](msg_t){ e(); } ); node_t F(g, [](msg_t){ f(); } ); make_edge(A, B); make_edge(B, C); make_edge(B, D); make_edge(A, E); make_edge(E, D); make_edge(E, F); A.try_put( continue_msg() ); g.wait_for_all(); return 0; }图中的边构成偏序A必须先于B和E完成B先于C、DE先于D、F而B与E、C与F之间没有顺序约束可以并行。若假设每个节点耗时相同为t全图顺序执行总时间T 6t共 6 个节点所有路径A→B→C、A→B→D、A→E→D、A→E→F都是 3 个节点长即C 3t因此理论最大加速比T/C 2。这与该文档给出的执行时间线图一致D必须等到B和E都完成之后才能开始墙钟时间不可能低于 3 个节点的耗时。2.3 上界的适用前提与失效场景T/C是一个乐观上界官方文档特别注明它忽略了微架构与内存效应。从依赖图的共享内存特性看节点通过共享内存而非消息边获取数据实际加速比还受以下因素影响多个并行节点同时读写共享内存时产生的缓存一致性开销与伪共享关键路径上相邻节点间的依赖唤醒延迟continue_node需要等齐所有前驱消息才生成任务线程数不足时部分已生成的任务需要等待线程可用——时间线图明确说明上图展示的是线程数足够的情形线程更少时任务会排队。因此正确的心智模型是T/C是天花板不是承诺。估算时应把测量到的加速比与该上界对比如果实测远低于上界说明问题在调度/内存等开销侧如果实测已逼近上界说明该依赖结构本身限制了扩展性继续加线程收益有限。oneTBB 仓库中的 examples/graph/cholesky/cholesky.cppdtrsm/dsyr2k/dpotf2节点构成的 Crout-Cholesky 依赖图就是这类大型依赖图的典型实例其性能分析同样适用上述方法。三、节点 body 默认被包装为任务粒度开销从何而来3.1 默认行为官方文档指出input_node、function_node、continue_node和multifunction_node的 body默认在生成的任务spawned task中执行。这意味着估算节点执行时间时必须把任务调度开销计算在内。所有关于任务粒度应取多大的经验法则同样适用于节点 body——如果 flow graph 中存在大量细粒度节点body 只有几纳秒到几百纳秒调度开销会显著侵蚀性能。源码中这条生成任务的路径清晰可见。以function_node/multifunction_node的输入端为例include/oneapi/tbb/detail/_flow_graph_node_impl.h 中try_put_task_base在非轻量路径下会走到create_body_task// _flow_graph_node_impl.h节选 graph_task* create_body_task( const input_type input ) { if (!is_graph_active(my_graph_ref)) { return nullptr; } d1::small_object_allocator allocator{}; graph_task* t nullptr; using task_type apply_body_task_bypassclass_type, input_type; t allocator.new_objecttask_type(my_graph_ref, allocator, *this, input, my_priority); return t; }即每收到一条消息就要分配一个 graph_task 对象经由 TBB 的小对象分配器并提交给图所在 arena 的工作池。这个对象分配 入队 出队 执行 释放的完整往返就是文档所说的调度开销其量级决定了节点 body 的最小有效粒度body 太短时净计算时间可能小于任务往返成本并行化反而不如内联执行。3.2 并发限制与排队策略的交互function_node构造时传入的concurrency参数决定了同时执行 body 的任务数上限Policy模板参数默认为queueing见 include/oneapi/tbb/flow_graph.h 中function_node的定义决定超限时消息是排队queueing还是拒绝rejecting即try_put返回false由前驱决定去留。从源码结构看排队路径通过聚合器aggregator串行化地检查并发计数、把多余消息缓存进输入队列后续任务完成后再从队列中补发——这条逻辑在try_put_task_impl的occupy_concurrency/perform_queued_requests操作中体现同文件 L312-L346 区域。因此估算含并发限制的节点时还需考虑限制越小节点越接近串行瓶颈段越有可能成为新的关键路径组成部分。四、lightweight 策略把任务调度开销内联掉文档给出的缓解手段是根据图结构对这些节点使用轻量lightweight策略来降低任务开销。这是 oneTBB 中少见的、直接以消除调度开销为目的的节点级配置。4.1 策略标签与默认值所有策略标签定义在 include/oneapi/tbb/detail/_flow_graph_body_impl.h 的graph_policy_namespace中struct rejecting { }; struct reserving { }; struct queueing { }; struct lightweight { }; // ... typedef Policyqueueing, lightweight queueing_lightweight; typedef Policyrejecting, lightweight rejecting_lightweight;各节点类型的默认策略摘自 include/oneapi/tbb/flow_graph.h 的模板声明如下节点类型Policy 模板参数默认值是否可用 lightweight 变体function_nodeL876queueingqueueing是queueing_lightweight/rejecting_lightweightmultifunction_nodeL964queueingqueueing是同上continue_nodeL1106Policyvoid无策略标签是可显式传入queueing_lightweightasync_nodeL2803queueing_lightweight已是queueing_lightweight—默认即轻量input_nodeL647无 Policy 参数—从模板上不适用轻量策略注意async_node默认就是queueing_lightweight从源码结构看这是因为它的设计意图就是让外部线程同步地把结果直接推进图内内联执行正是其语义所需。4.2 源码机制从生成任务到直接执行 bodylightweight策略的核心效果是消息到达时不再分配 graph_task而是由当前线程直接执行 body再转发给后继。关键代码在 include/oneapi/tbb/detail/_flow_graph_node_impl.hgraph_task* try_put_task_base(const input_type t __TBB_FLOW_GRAPH_METAINFO_ARG(const message_metainfo metainfo)) { if ( my_is_no_throw ) return try_put_task_impl(t, has_policylightweight, Policy() __TBB_FLOW_GRAPH_METAINFO_ARG(metainfo)); else return try_put_task_impl(t, std::false_type() __TBB_FLOW_GRAPH_METAINFO_ARG(metainfo)); } graph_task* try_put_task_impl( const input_type t, /*lightweight*/std::true_type ...) { if( my_max_concurrency 0 ) { return apply_body_bypass(t ...); // 无并发限制直接执行 body } else { operation_type check_op(t, occupy_concurrency); my_aggregator.execute(check_op); if( check_op.status SUCCEEDED ) { return apply_body_bypass(t ...); // 占到一个并发名额当前线程直接执行 } return internal_try_put_bypass(t ...); // 名额已满缓存进输入队列 } }与默认的create_body_task分配任务对象再入池不同apply_body_bypass同文件 L474-L504在当前线程内联调用body随后把输出try_put_task给后继若后继没有返回可执行任务轻量节点直接回报SUCCESSFULLY_ENQUEUED让消息流沿内联链继续向下游推进。对continue_node同文件 L779-L784 的execute中同样有分支轻量策略下依赖满足时直接apply_body_bypass(continue_msg())跳过任务对象分配。也就是说一条由轻量节点构成的依赖链上消息传递 body 执行可以在同一个线程的调用栈内连续推进只有当并发名额不足或需要让出控制权时才会真正落回任务池。这正是文档所说的可以减少此类开销的实现基础。4.3 关键前提body 必须不抛异常try_put_task_base的第一个判断是my_is_no_throw。该标志在节点构造时由noexcept(tbb::detail::invoke(body, input_type()))确定include/oneapi/tbb/detail/_flow_graph_node_impl.h。这意味着如果 body 可能抛出异常即使显式指定了queueing_lightweight实现也会自动退回默认的任务生成路径——因为内联执行会把异常直接抛出消息发送方的调用栈破坏 flow graph 的异常传递协议节点内异常需要通过图的任务机制收集与传播参见 doc/main/tbb_userguide/Flow-Graph-exception-tips.rst因此改造节点为轻量策略前先确认 body 可以用noexcept语义表达若 body 必须处理异常可考虑在节点内捕获并降级或放弃轻量策略。4.4 使用方式以continue_node为例把默认任务化写法oneapi::tbb::flow::continue_nodeoneapi::tbb::flow::continue_msg n(g, [](auto){ ... });改为轻量写法oneapi::tbb::flow::continue_nodeoneapi::tbb::flow::continue_msg, oneapi::tbb::flow::queueing_lightweight n(g, [](auto) noexcept { ... });function_node/multifunction_node则通过构造函数的Policy参数传入oneapi::tbb::flow::queueing_lightweight模板默认值为queueing。测试代码中对这些类型别名的引用可参见 test/common/graph_utils.h 与 test/tbb/test_tbb_header.cpp。五、估算流程小结两条主线一起用综合以上两部分对任意一个 oneTBB flow graph 可以按如下流程估算性能与可扩展性画依赖结构算关键路径把图抽象为偏序找出耗时最长的路径C与顺序执行总量T得到加速比上界T/C。对数据流图还需考虑消息缓冲与并发限制function_node的concurrency参数、rejecting策略下的重试路径对等效关键路径的影响清点细粒度节点统计 body 执行时间接近或小于任务调度往返成本的节点数量。这类节点在默认策略下每条消息都触发一次 graph_task 分配与入池见第三节create_body_task对适合内联的节点启用轻量策略将function_node/multifunction_node/continue_node的 Policy 改为queueing_lightweight或rejecting_lightweight前提是 body 可noexcept注意async_node默认已是轻量策略input_node的模板不接受 Policy回归验证用wait_for_all前后的实测墙钟时间与T/C上界对比。若实测远低于上界优先排查第 2 步的调度开销与第 2 节的共享内存竞争若已逼近上界则应重构依赖结构拆分/合并关键路径上的节点而非继续增加线程。需要再次强调适用边界T/C公式忽略微架构与内存效应是上界而非预测值lightweight策略依赖不抛异常的 body且并发限制仍生效——名额已满的消息依旧走缓存队列路径。把这两点纳入估算才能对 flow graph 的性能建立起既乐观又可靠的判断。赞分享并发编程高性能计算【免费下载链接】oneTBBoneAPI Threading Building Blocks (oneTBB)项目地址https://gitcode.com/gh_mirrors/on/oneTBB点击查看免费下载相关推荐oneTBB Flow Graph 节点优先级node_priorities深入解析用关键路径优先调度提升并行图性能oneTBB Flow Graph 节点优先级node_priorities深入解析用关键路径优先调度提升并行图性能 本文基于当前仓库内嵌的 oneTBB开发工具构建工具系统编程oneTBB Flow Graph 资源受限节点Resource-limited NodesRFC 深度解析从 flow::serial 到跨节点共享资源串行化oneTBB Flow Graph 资源受限节点Resource limited NodesRFC 深度解析从 flow::serial 到跨节点共享资源开发工具构建工具系统编程oneTBB Flow Graph 资源受限节点Resource-limited NodesRFC 深度解读从 flow::serial 到跨节点共享资源序列化oneTBB Flow Graph 资源受限节点Resource limited NodesRFC 深度解读从 flow::serial 到跨节点共享资源并发编程高性能计算上一篇5分钟用WeChatMsg导出微信聊天记录一次搞定永久保存和报告下一篇无主之地3存档编辑器3 步改满等级背包再塞一把传奇创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考