Broaden #1003 into a shared CPU/GPU elementwise framework (follow-up to #1067)
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- cpp
- 领域
- backend, performance
调研方向
Start by reading #1003, #1067, and the traversal in cuArithmeticDispatch.cuh, cuiArithmeticDispatch.cuh, and cuCpr_dispatch.cu; compare with the CPU traversal from #1056. The issue lists six redesign items, including shared layout metadata, rank limits, and mapper fast paths. Benchmark the listed operand layouts across sizes and ranks; done means the shared framework addresses the listed correctness and reachability gaps and includes comparative benchmarks.
由索引模型根据 Issue 内容生成。
描述
Context
Follow-up to PR #1067, which converts GPU elementwise arithmetic to typed
std::visit dispatch and removes the legacy per-dtype tables. In his review of
#1067, @ianmccul noted that the non-contiguous mapper kernels introduced/carried
forward there should be treated as transitional code, and that the broader
work tracked in #1003 should be broadened to a shared CPU/GPU elementwise
framework. This issue collects the concrete items from that review so they aren't
lost.
The typed-dispatch cleanup and dtype-correctness fixes in #1067 are independently
worthwhile and can land first; the items below are the follow-up.
Architecture (broaden #1003)
Move to a single shared CPU/GPU elementwise framework:
- common operation functors and dtype/promotion policies (the functor is already
shared within one GPU arithmetic family, but traversal is not), - common host-side stride/layout preprocessing into one compact,
trivially-copyable layout descriptor, - backend-specific CPU/CUDA execution that consumes the same descriptor.
This removes the traversal duplication that currently exists across
cuArithmeticDispatch.cuh, cuiArithmeticDispatch.cuh, cuCpr_dispatch.cu, and
the analogous CPU traversal from #1056.
Concrete items
-
Rank-dependent shared-memory launch limit (correctness). The non-contiguous
kernels request512 * rank * sizeof(uint64_t) = 4096 * rankbytes of dynamic
shared memory for per-thread coordinate vectors. Rank 13 already exceeds the
common 48 KiB limit, so high-rank non-contiguous arithmetic fails at launch with
no rank check or fallback. (Pre-existing: inherited from the legacy kernels.)
Fix by not putting the per-thread coordinate vector in dynamic shared memory, or
at minimum add an explicit supported-rank check / rank-derived block size. -
Pass layout metadata as a kernel argument, not via managed allocations. Each
non-contiguous op currently does 5cudaMallocManagedallocations + 2 copies +
launch + 5 frees for a few hundred bytes of metadata. Pack extents/strides/
mappers into one trivially-copyable struct passed by value (e.g.
__grid_constant__ LayoutMetadatawithstd::array<uint64_t, MAX_RANK>fields;
~1.3 KiB at rank 32, well under the 32 KiB parameter limit on modern devices),
or copy once withcudaMemcpyAsync/ prefetch. (Gemini's "host write to device
pointer" flag was a false positive —cuCalloc_gpuiscudaMallocManaged— but
demand-paging tiny managed allocations is still a poor metadata path.) -
In-place: iterate LHS physical order; only map the RHS. For in-place ops the
LHS is also the output, so traversing LHS physical order guarantees coalesced
LHS reads and output writes; only the RHS may need an index transform. Compose
the two permutations host-side into a single LHS-physical -> RHS-physical map.
The current kernel redundantly decodes a logical index, computesLidx, then
Ridx, and writesout[Lidx]. -
Same-layout fast path. When
Lt.shape() == Rt.shape() && Lt.invmapper() == Rt.invmapper(), corresponding logical elements share physical offsets, so the op
is a plain physical-buffer zip (out[i] = op(lhs[i], rhs[i])) with no mapper --
true even for non-commutative ops. Today the front end takes the full mapper path
whenever either operand is individually non-contiguous, so two identically
permuted operands pay the whole mapper cost unnecessarily. -
Uniform non-contiguous reachability. Out-of-place GPU
Mul/Div/Mod/Cpr
front ends still reject (or contiguous-ize) non-contiguous tensor/tensor
operands; onlyAdd/Suband the in-place paths reach the mapper-aware kernels.
The shared framework should make the mapper-aware kernel uniformly reachable. -
Benchmarks to guide the redesign. Before treating the mapper path as final,
benchmark (over multiple sizes/ranks): contiguousa += b; identically permuted
a += b(should match contiguous once the fast path exists); contiguous LHS +
permuted RHS; differently permuted operands; andcontiguous()-copy-then-zip
including copy cost.
Credit: findings and suggestions by @ianmccul (posted via OpenAI Codex) on #1067.
Related: #1003, #1067.
- 主要语言
- C++
- 星标
- 62
- 派生
- 23
- 平均合并
- 4 天 10 小时
- 30 天内合并 PR
- 3
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
Cytnx-dev/Cytnx 的其他 Issue
-
document that `min_blockdim` is a positional per-block floor that can exceed `keepdim`可能已有人在做 @pcchen 于 1 天前认领。 未关闭documentation
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 2/5 1-3 小时 新手友好度 76/100
-
难度 1/5 1-3 小时 新手友好度 75/100
-
bug compile/build
难度 2/5 1-3 小时 新手友好度 76/100
-
难度 1/5 1 小时以内 新手友好度 76/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
DarkCastleMUD/DarkCastle#283 ·
-
难度 2/5 1-3 小时 新手友好度 62/100
-
-priority- blocked good first issue help wanted
难度 2/5 1-3 小时 新手友好度 68/100
scribe-org/Scribe-Android#761 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
Bug Testing
难度 2/5 1-3 小时 新手友好度 78/100
SCIInstitute/SCIRun#2931 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 5 天内回复