From 1c618a48073b6ff06f6b2ef087a1ca7d52de44d3 Mon Sep 17 00:00:00 2001 From: "Bryan C. Mills" Date: Wed, 27 Jun 2018 18:00:00 -0400 Subject: [PATCH] Updated AssemblyPolicy (markdown) --- AssemblyPolicy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/AssemblyPolicy.md b/AssemblyPolicy.md index a762f47b..ae00237c 100644 --- a/AssemblyPolicy.md +++ b/AssemblyPolicy.md @@ -6,9 +6,9 @@ In general, the rules are: * We prefer portable Go, not assembly. Code in assembly means (N packages * M architectures) to maintain, rather than just N packages. -* Minimize use of assembly. We'd rather have a small amount of assembly for a 50% speedup rather than twice as much assembly for a 55% speedup. Explain the decision to place the assembly/Go boundary where it is, and support it with benchmarks. +* Minimize use of assembly. We'd rather have a small amount of assembly for a 50% speedup rather than twice as much assembly for a 55% speedup. Explain the decision to place the assembly/Go boundary where it is, and support it with benchmarks in the commit message. -* Explain the root causes. What changes in the compiler and standard library would allow you to replace this assembly with Go? (New intrinsics, SSA pattern matching, other optimizations.) +* Explain the root causes in code comments or commit messages. What changes in the compiler and standard library would allow you to replace this assembly with Go? (New intrinsics, SSA pattern matching, other optimizations.) * Make your assembly easy to review; ideally, auto-generate it using a simpler Go program. Comment it well.