Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› ppopp-writing-style
ppopp-writing-style
GitHub用于撰写或优化PPoPP论文，涵盖两列acmart排版、10页篇幅限制及无限参考文献。强调前置声明并发正确性与可扩展性主张，展示加速曲线与核心扫描数据，遵循并行编程惯例以满足专家审稿人要求。
Trigger Scenarios
起草PPoPP会议论文初稿
优化论文结构与行文风格
检查并发正确性与可扩展性声明
调整两列排版与图表布局
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill ppopp-writing-style -g -y
SKILL.md
Frontmatter
{
"name": "ppopp-writing-style",
"description": "Use when drafting or tightening a PPoPP paper's prose and structure, covering the two-column acmart sigplan layout, the 10-page text+figures budget, stating the concurrency-correctness and scalability claim up front, presenting speedup curves and core sweeps, and the parallel-programming conventions PPoPP reviewers expect."
}
PPoPP Writing Style
Write to the PPoPP bar: a parallel-programming contribution that is correct under concurrency and
measurably scalable, presented in two-column acmart sigplan within 10 pages of text
and figures (references unlimited). The reader is a parallel-systems expert who will look for the
speedup curve, the baseline, and the correctness argument before they finish the introduction.
The first-page contract
By the end of page 1 a PPoPP reviewer should know:
- The parallel-programming problem — what breaks or stalls when you go parallel (contention, a sequential bottleneck, poor locality, divergence, a memory-model hazard).
- The contribution — the structure, runtime, algorithm, or technique, in one sentence, framed so parallelism is clearly the point (not a compiler pass or a proof in disguise).
- The twin claim — that it is correct under concurrency and how much it scales, with the headline number ("linear to 96 cores," "1.8× over the state-of-the-art lock-free map at 64 threads").
- The evidence shape — the hardware, the workloads, and the baseline you beat.
A PPoPP introduction that describes a mechanism but never states a scaling number, or that promises correctness without naming the concurrency hazard it handles, reads as unfinished.
Two-column, 10-page discipline
- The two-column
acmartlayout is unforgiving of wide figures. Speedup plots, roofline charts, and code listings must fit one column or span both deliberately — plan figure placement early. - 10 pages of text and figures; references are free, so cite fully (all authors, no "et al.").
Do not pad the body with material that belongs in the artifact (
ppopp-supplementary). - Recover space by cutting prose, merging plots (small multiples of a core sweep beat five separate charts), and pushing full sweeps to the artifact — never by shrinking the template.
Structure that fits the venue
1 Introduction problem -> contribution -> twin claim (correctness + scaling) -> evidence
2 Background/Model the concurrency model, memory model, and hardware assumptions you rely on
3 Design the structure/runtime/algorithm; where parallelism is exposed and bounded
4 Correctness the argument: linearizability/progress, race-freedom, or a checked property
5 Implementation what a reader needs to reproduce: pinning, allocation, topology awareness
6 Evaluation speedup curves, core/GPU sweeps, NUMA effects, variance, baselines
7 Related work delta-first against the nearest parallel-programming competitor
8 Conclusion
Sections 4 and 6 are the twin load-bearing walls: skip the correctness argument and a reviewer distrusts the speedups; skip the sweep and they distrust the correctness claim's relevance.
Presenting parallel performance
- Show the curve, not one point. Report throughput/speedup as a function of thread or core count; a single configuration hides where you saturate or collapse.
- Name the baseline and the machine in the caption. "Speedup over
on a 2-socket 96-core node" — an unlabeled y-axis or an unnamed baseline invites a reject. - Show variance. Repeated runs with error bars; a bar chart of single runs reads as noise.
- Be honest about where it stops scaling. A paper that explains its saturation point is stronger than one that hides it behind a truncated x-axis.
Language conventions
- Prefer precise concurrency vocabulary: linearizable, lock-free vs. wait-free, quiescent consistency, false sharing, memory-order (acquire/release/seq_cst), work-span, strong vs. weak scaling. Reviewers read imprecision here as inexperience.
- Distinguish strong scaling (fixed problem, more cores) from weak scaling (problem grows with cores) explicitly; conflating them is a classic PPoPP tell.
- State the memory model you assume (C/C++11, the GPU model, hardware TSO) rather than leaving it implicit.
Common PPoPP writing failures
- A mechanism with no number — design described lovingly, scaling never quantified.
- A number with no machine — speedups whose hardware and baseline are unstated.
- Correctness by testing — "no data race observed" without an argument over interleavings.
- Strawman baselines — beating your own unoptimized code instead of the real competitor.
- Wide figures that overflow the column — a two-column layout problem, caught at compile time.
Output format
[First-page contract] problem / contribution / twin claim (correctness+scaling) / evidence — all present?
[Format] two-column acmart sigplan, <=10 pages text+figs, refs full (no et al.)?
[Correctness] hazard named + argument (linearizability/progress/race-freedom)? yes/no
[Scaling] curve over cores/GPU, named baseline, named machine, variance shown? yes/no
[Cut list] prose/figures to trim or move to the artifact to hit 10 pages
Version History
- 9f86f09 Current 2026-07-19 17:18
