Merge branch 'master' into feedburner

Author: axgillies

_posts/2018-02-15-totw-88.md

@@ -104,7 +104,7 @@ variable?", both to follow in your own code and to cite in your code reviews:
   ```cpp
   // Bad code
 
-  // Could invoke an intializer list constructor, or a two-argument constructor.
+  // Could invoke an initializer list constructor, or a two-argument constructor.
   Frobber frobber{size, &bazzer_to_duplicate};
 
   // Makes a vector of two doubles.

_posts/2018-09-28-totw-152.md

@@ -81,7 +81,7 @@ TEST(MyType, SupportsAbslHash) {
 }
 </pre>
 
-`absl::VerifyTypeImplementsAbslHashCorrectly` also supports testing heterogenous
+`absl::VerifyTypeImplementsAbslHashCorrectly` also supports testing heterogeneous
 lookup and custom equality operators.
 
 Intrigued and want to know more? Read up at

_posts/2023-02-15-totw-198.md

@@ -132,7 +132,7 @@ readable code. Take the following example:
 // with std::in_place.
 std::optional<Foo> with_tag(std::in_place, 5, 10);
 
-// Here the intent is clearer: make an optional Foo by providing these argments.
+// Here the intent is clearer: make an optional Foo by providing these arguments.
 std::optional<Foo> with_factory = std::make_optional<Foo>(5, 10);
 </pre>
 

_posts/2023-03-02-fast-21.md

@@ -12,7 +12,7 @@ Originally posted as Fast TotW #21 on January 16, 2020
 
 *By [Paul Wankadia](mailto:[email protected]) and [Darryl Gove](mailto:[email protected])*
 
-Updated 2023-03-02
+Updated 2024-10-21
 
 Quicklink: [abseil.io/fast/21](https://abseil.io/fast/21)
 

_posts/2023-03-02-fast-39.md

@@ -12,7 +12,7 @@ Originally posted as Fast TotW #39 on January 22, 2021
 
 *By [Chris Kennelly](mailto:[email protected]) and [Alkis Evlogimenos](mailto:[email protected])*
 
-Updated 2023-10-10
+Updated 2025-03-24
 
 Quicklink: [abseil.io/fast/39](https://abseil.io/fast/39)
 
@@ -146,14 +146,14 @@ would "reduce" the
 [data center tax](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44271.pdf),
 but we would actually hurt [application productivity](/fast/7)-per-CPU. Time we
 spend in malloc is
-[less important than application performance](https://research.google/pubs/pub50370.pdf).
+[less important than application performance](https://storage.googleapis.com/gweb-research2023-media/pubtools/6170.pdf).
 
 Trace-driven simulations with hardware-validated architectural simulators showed
 the prefetched data was frequently used. Additionally, it is better to stall on
 a TLB miss at the prefetch site--which has no dependencies, than to stall at the
 point of use.
 
-## Pitfalls
+## Pitfalls {#pitfalls}
 
 There are a number of things that commonly go wrong when writing benchmarks. The
 following is a non-exhaustive list:
@@ -175,15 +175,23 @@ following is a non-exhaustive list:
     [Stabilizer (by Berger, et. al.)](https://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf)
     deliberately perturb these parameters to improve benchmarking statistical
     quality.
+*   Sensitivity to stack alignment. Changes anywhere in the stack--added/removed
+    variables, better (or worse) spilling due to compiler optimizations,
+    etc.--can affect the alignment at the start of the function-under-test. This
+    has been seen to produce 20% performance swings.
 *   Representative data. The data in the benchmark needs to be "similar" to the
     data in production - for example, imagine having short strings in the
     benchmark, and long strings in the fleet. This also extends to the code
     paths in the benchmarks being similar to the code paths that the application
-    exercises.
+    exercises. This is a common pain point for macrobenchmarks too. A loadtest
+    may cover certain request types, rather than all of those seen by production
+    servers.
+
 *   Benchmarking the right code. It's very easy to introduce code into the
     benchmark that's not present in the real workload. For example, using a
     random number generator's cost for a benchmark could exceed the cost of the
     work being benchmarked.
+
 *   Being aware of steady state vs dynamic behaviour. For more complex
     benchmarks it's easy to produce something that converges to a steady state -
     for example if it has a constant arrival rate and service time. Production

_posts/2023-03-02-fast-53.md

@@ -12,7 +12,7 @@ Originally posted as Fast TotW #53 on October 14, 2021
 
 *By [Mircea Trofin](mailto:[email protected])*
 
-Updated 2023-09-04
+Updated 2024-11-19
 
 Quicklink: [abseil.io/fast/53](https://abseil.io/fast/53)
 

_posts/2023-03-02-fast-9.md

@@ -12,7 +12,7 @@ Originally posted as Fast TotW #9 on June 24, 2019
 
 *By [Chris Kennelly](mailto:[email protected])*
 
-Updated 2023-10-10
+Updated 2025-03-27
 
 Quicklink: [abseil.io/fast/9](https://abseil.io/fast/9)
 
@@ -64,7 +64,7 @@ Prior to cleanups, the implementations weren't the same.
     working around a
     [false dependency bug](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011)
     in some processors.
-*   When the compiler builtin is used (the "slow" version), we actually end up
+*   When the compiler built-in is used (the "slow" version), we actually end up
     with a better sequence of machine code and can perform stronger
     optimizations at compile-time around constant folding.
 

_posts/2023-09-14-fast-7.md

@@ -12,7 +12,7 @@ Originally posted as Fast TotW #7 on June 6, 2019
 
 *By [Chris Kennelly](mailto:[email protected])*
 
-Updated 2023-10-31
+Updated 2025-03-25
 
 Quicklink: [abseil.io/fast/7](https://abseil.io/fast/7)
 
@@ -75,7 +75,7 @@ optimizations* that are not well-represented by existing metrics:
     produce outsized benefits for the entire application.
 
 *   **New instruction sets**: With successive hardware generations, vendors have
-    added new instrutions to their ISAs.
+    added new instructions to their ISAs.
 
     In future hardware generations, we expect to replace calls to memcpy with
     microcode-optimized `rep movsb` instructions that are faster than any

_posts/2023-09-30-fast-52.md

@@ -12,7 +12,7 @@ Originally posted as Fast TotW #52 on September 30, 2021
 
 *By [Chris Kennelly](mailto:[email protected])*
 
-Updated 2023-09-30
+Updated 2025-03-24
 
 Quicklink: [abseil.io/fast/52](https://abseil.io/fast/52)
 
@@ -130,13 +130,14 @@ test, and successfully land new features in production. Beyond just optimizing
 Extra complexity that delays an improvement to product experiences is a
 non-obvious externality.
 
-For example, TCMalloc has a number of tuning options and customization points,
-but ultimately, several optimizations came from sanding away extra configuration
-complexity. The rarely used malloc hooks API required careful structuring of
-TCMalloc's fast path to allow users who didn't use hooks--most users--to not pay
-for their possible presence. In another case, removing the `sbrk` allocator
-allowed TCMalloc to structure its virtual address space carefully, enabling
-several enhancements.
+For example, TCMalloc has a number of
+[tuning options](https://github.com/google/tcmalloc/blob/master/docs/tuning.md)
+and customization points, but ultimately, several optimizations came from
+sanding away extra configuration complexity. The rarely used malloc hooks API
+required careful structuring of TCMalloc's fast path to allow users who didn't
+use hooks--most users--to not pay for their possible presence. In another case,
+removing the `sbrk` allocator allowed TCMalloc to structure its virtual address
+space carefully, enabling several enhancements.
 
 ## Beyond knobs
 
@@ -147,7 +148,7 @@ An existing library, *X*, might be inadequate or insufficiently expressive,
 which can motivate building a "better" alternative, *Y*, along some dimensions.
 Realizing the benefit of using *Y* is dependent on users both discovering *Y*
 and picking between *X* and *Y* *correctly*--and in the case of a long-lived
-code base, keeping that choice optimal over time.
+codebase, keeping that choice optimal over time.
 
 For some uses, this strategy is infeasible. `my::super_fast_string` will
 probably never replace `std::string` because the latter is so entrenched and the

_posts/2023-10-10-fast-64.md

@@ -12,7 +12,7 @@ Originally posted as Fast TotW #64 on October 21, 2022
 
 *By [Chris Kennelly](mailto:[email protected])*
 
-Updated 2023-10-10
+Updated 2025-03-24
 
 Quicklink: [abseil.io/fast/64](https://abseil.io/fast/64)
 
@@ -42,10 +42,10 @@ preconditions to unlock the best possible performance. We need to document and
 test these sharp edges. Future debugging has an opportunity cost: When we spend
 time tracking down and fixing bugs, we are not developing new optimizations. We
 can use assertions for preconditions, especially in debug/sanitizer builds, to
-double-check contracts and *enforce* them. Testing robots never sleep, while
-humans are fallible. Randomized implementation behaviors provide a useful
-bulwark against Hyrum's Law from creeping in to implicitly expand the contract
-of an interface.
+double-check contracts and *enforce* them. Testing
+[robots never sleep](/fast/93), while humans are fallible. Randomized
+implementation behaviors provide a useful bulwark against Hyrum's Law from
+creeping in to implicitly expand the contract of an interface.
 
 ## Express intents
 
@@ -124,11 +124,11 @@ memory.
 
 ## Avoid unnecessarily strong guarantees
 
-There are situations where the benefits of duplicate APIs outweight the costs.
+There are situations where the benefits of duplicate APIs outweigh the costs.
 
 The Abseil hash containers
 ([SwissMap](https://abseil.io/about/design/swisstables)) added new hashtable
-implementations to the code base, which at first glance, appear redundant with
+implementations to the codebase, which at first glance, appear redundant with
 the ones in the C++ standard library. This apparent duplication allowed us to
 have a more efficient set of containers which match the standard library API,
 but adhere to a weaker set of constraints.
@@ -140,6 +140,11 @@ to a node-based implementation that requires data indirections and constrains
 performance. Given `std::unordered_map`'s widespread usage, it was not feasible
 to relax these guarantees all at once.
 
+Node-based containers necessitate implementation overheads, but they come with a
+direct benefit: They actively facilitate migration while allowing weaker
+containers to be available. Making a guarantee stronger without an accompanying
+benefit is undesirable.
+
 The migration was a replacement path for the legacy containers, not an
 alternative. The superior performance characteristics meant that users could
 "just use SwissMap" without tedious benchmarking on a case-by-case basis.
@@ -218,7 +223,7 @@ constrain future implementations by creating sharp performance edges.
     higher-level intent--transferring pointer ownership, "lending" a submessage
     to another one, etc.
 
-### Concluding remarks
+## Concluding remarks
 
 Good performance should be available by default, not an optional feature. While
 [feature flags and knobs can be useful for testing and initial rollout](/fast/52),