Add: parallel for iteration isolation in tensormap and orchestrator

[zhusy54]

Summary

• Add PTO2_PARALLEL_FOR / PTO2_PARALLEL_SCOPE macros and RAII guards that bracket each loop iteration with a scope-level dependency filter
• Record iter_start_local_ids per ring in PTO2TensorMap so that tensor-map lookups skip entries produced in prior iterations on the same ring, preventing false cross-iteration dependencies when independent loop iterations submit tasks concurrently
• Wire new parallel_for_begin/end and parallel_scope_begin/end ops into PTO2RuntimeOps vtable

Changes

• pto_orchestration_api.h: new parallel_for_begin/end and parallel_scope_begin/end ops, inline wrappers, RAII guards, PTO2_PARALLEL_FOR / PTO2_PARALLEL_SCOPE macros (a2a3 + a5)
• pto_orchestrator.h/.cpp: implement pto2_parallel_for/scope_begin/end using existing scope stack + iter_start filter bookkeeping
• pto_tensormap.h/.cpp: add iter_start_local_ids[ring] array, initialise to -1, filter stale entries during lookup
• pto_ring_buffer.h: expose next_local_id() for snapshot at scope entry
• pto_runtime2.h/.cpp: wire new ops into PTO2RuntimeOps vtable

Testing

• All tests pass
• Code review completed

[gemini-code-assist]

Code Review

This pull request introduces parallel-for iteration isolation for the PTO2 runtime. It adds lifecycle hooks to the runtime operations, implements RAII guards and macros for parallel scopes, and updates the PTO2TensorMap lookup logic to filter out tensor entries from previous iterations using per-ring local task IDs. These changes are applied consistently across the a2a3 and a5 runtime paths. I have no feedback to provide.

[zhusy54]

硬件性能测试结果

在 Ascend NPU (device-8) 上对 本 PR（parallel） 与 main 分支（0745dee1） 进行了基准测试对比。

测试环境

• Runtime: tensormap_and_ringbuffer
• 每个用例运行 100 rounds，取 Trimmed Avg（去掉最高/最低各 10 个数据点，80 rounds 均值）
• Base：main 分支（不含本 PR 改动），跑 2 轮
• Parallel：本 PR 分支（含 PTO2_PARALLEL_FOR / iteration isolation 改动），跑 3 轮

对比结果

用例	Base Trimmed Avg	Parallel Trimmed Avg	Elapsed Δ	Orch Δ
alternating_matmul_add (Case1)	814.2 µs	756.9 µs	-7.0% ✅	-9.6% ✅
benchmark_bgemm (Case0)	736.6 µs	685.9 µs	-6.9% ✅	-9.5% ✅
paged_attention_unroll (Case1)	1132.4 µs	1135.9 µs	+0.3%	+2.5%
paged_attention_unroll (Case2)	517.1 µs	518.0 µs	+0.2%	~0%
batch_paged_attention (Case1)	2824.9 µs	2842.6 µs	+0.6%	~0%

Base 均值 = 2 轮 Trimmed Avg 的平均；Parallel 均值 = 3 轮 Trimmed Avg 的平均。

各轮次明细（Trimmed Avg, µs）

用例	Base R1	Base R2	Para R1	Para R2	Para R3
alternating_matmul_add	810.1	818.3	760.6	761.3	748.7
benchmark_bgemm	730.9	742.2	687.2	687.2	683.2
paged_attention_unroll C1	1131.6	1133.2	1139.9	1133.6	1134.1
paged_attention_unroll C2	518.4	515.8	518.1	519.7	516.3
batch_paged_attention	2833.7	2816.1	2835.5	2846.2	2846.2

分析

1. alternating_matmul_add / benchmark_bgemm 提升明显（Elapsed ≈ -7%，Orch ≈ -9.5%）：这两个用例调度开销占比较大，parallel dispatch 使独立迭代可以并发提交任务，减少了调度等待，收益显著。

2. paged_attention / batch_paged_attention 基本持平（偏差 < 1%，属噪声范围）：这类用例计算密集，调度开销相对较小，parallel dispatch 的调度收益被计算时间掩盖。

3. Orch 提升 > Elapsed 提升：说明 parallel isolation 主要优化了 orchestration 阶段的调度效率，符合预期。

4. 数据稳定性良好：各轮次波动小（< 1%），结果可信。

注：Parallel Round 1 的 paged_attention_unroll Case2 出现了两个异常值（8203 µs、4518 µs），已被 Trimmed Avg 正确过滤。