ppopp-related-work
GitHub指导撰写或审核PPoPP论文的相关工作部分，聚焦并行编程领域。强调与最接近竞品进行可量化的增量对比，覆盖数据结构、运行时等关键方向，并遵循双盲评审规范。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill ppopp-related-work -g -y
SKILL.md
Frontmatter
{
"name": "ppopp-related-work",
"description": "Use when writing or auditing a PPoPP paper's related-work and positioning, covering the parallel-programming literature lanes (concurrent data structures, runtimes\/schedulers, GPU\/accelerators, memory models, parallel algorithms), delta-first comparison against the nearest competitor, double-blind self-citation, and separating PPoPP work from CGO\/PLDI\/POPL\/SC neighbors."
}
PPoPP Related Work
Position the paper against the parallel-programming literature, not the whole of systems. A PPoPP reviewer is an expert in your subarea and will know the two or three works you must beat. The job is delta-first: state precisely what your structure/runtime/algorithm does that the nearest prior parallel-programming work does not, in measurable terms.
Cover the right lanes
Map your contribution onto the PPoPP literature lanes and cover the ones you touch:
- Concurrent data structures — lock-free/wait-free lists, maps, queues, skip lists; progress guarantees; memory reclamation (hazard pointers, epoch-based, RCU).
- Runtimes and schedulers — work-stealing, task graphs, futures, fork/join, load balancing, parallel-loop scheduling.
- GPU and accelerator programming — kernel design, occupancy/divergence, heterogeneous scheduling, memory movement, warp-level primitives.
- Memory models and concurrency correctness — weak-memory reasoning, race detection, linearizability checking, verified concurrency.
- Parallel algorithms in practice — graph, sparse, numerical kernels; locality/NUMA engineering.
- Parallel languages/compilers-for-parallelism — DSLs, parallel IRs, runtime-coupled compilation (cite, but position against CGO/PLDI so the boundary is clear).
Missing the lane your reviewer works in is the fastest way to look like a visitor.
Delta-first, in measurable terms
- Lead each comparison with the delta: "Unlike
, which requires a global lock on resize, our structure resizes lock-free, giving <X>× throughput at 64 threads." Contrast on the axis PPoPP cares about — progress guarantee, contention behavior, scalability, memory overhead. - Do not merely list neighbors; say what each one cannot do that you do, and where you inherit from them honestly.
- If your only delta over the state of the art is a single-machine constant-factor speedup with no qualitative difference, say so plainly — reviewers will find the gap faster than you can hide it.
The nearest-competitor test
For every contribution, name the single closest prior parallel-programming work and answer:
[Same problem?] are they solving the same parallel-programming problem, or an adjacent one?
[Progress/model] do you offer a stronger guarantee (wait-free vs lock-free, stronger memory model)?
[Scaling] where does their approach saturate that yours does not, and by how much?
[Cost] what do you pay (space, single-thread overhead) that they do not — stated honestly?
If you cannot articulate the delta on at least one of these axes, the paper is not yet positioned.
Double-blind self-citation
PPoPP review is double-blind. Cite your own prior work in the third person ("Prior work [12] introduced...") — never "our earlier system [12]." Watch the parallel-systems-specific leaks:
- A distinctive system/library/runtime name carried from your prior paper that identifies the group.
- A results repository or benchmark suite hosted under a personal/lab account, cited in-line.
- Acknowledgement of a specific named machine or grant that pins the institution.
Anonymize the artifact link and describe carried-over systems neutrally until camera-ready.
Separating PPoPP from its neighbors in the prose
Because PPoPP shares its week with CGO/CC and its subject with PLDI/POPL/SC, reviewers watch for scope drift in the related work:
- Cite compiler-optimization work but frame your delta as a parallel-execution result, not a pass — otherwise you invite a "this is a CGO paper" comment.
- Cite concurrency-theory work but anchor your contribution to a measured system — a pure-logic framing reads as POPL.
- Cite HPC-at-scale work but keep the lesson a general parallel-programming one, not a single-deployment report — otherwise SC is the home.
Common failures
- A wall of citations with no deltas — reads as a literature dump, not positioning.
- Missing the reviewer's own lane — the one omission that most reliably angers a PC member.
- First-person self-citation — a double-blind violation that is easy to miss under deadline.
- Comparing only to old baselines — the state of the art in concurrent structures and GPU kernels moves fast; a 5-year-old baseline is not the frontier.
Output format
[Lanes covered] which parallel-programming lanes your positioning addresses
[Nearest competitor] named, with the delta on progress/model | scaling | cost
[Delta statements] each measurable and axis-specific? yes/no
[Anonymity] self-citations third-person? system name / repo / machine anonymized? yes/no
[Scope guard] framed as parallel-programming (not CGO/POPL/SC)? yes/no
Version History
- 9f86f09 Current 2026-07-19 17:17
