Final tweaks

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/02-bitmap-data-structure.md

@@ -83,6 +83,6 @@ size_t bitvector_count_scalar(bitvector_t* bv) {
 }
 ```
 
-## Next up: Implement and benchmark your first scalar bitmap scan
+## Next up: implement and benchmark your first scalar bitmap scan
 
 With your bit vector infrastructure in place, you're now ready to scan it for set bits—the core operation that underpins all bitmap-based filters in database systems.

content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/03-scalar-implementations.md

@@ -76,7 +76,7 @@ size_t result_count = 0;
 ```
 Instead of iterating through each bit individually, this implementation processes one byte (8 bits) at a time. The main optimization over the previous scalar implementation is checking if an entire byte is zero and skipping it entirely. For sparse bitmaps, this can dramatically reduce the number of bit checks.
 
-## Next up: Accelerate bitmap scanning with NEON and SVE
+## Next up: accelerate bitmap scanning with NEON and SVE
 
 You’ve now implemented two scalar scanning routines:
 

content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/04-vector-implementations.md

@@ -10,9 +10,12 @@ layout: "learningpathall"
 ---
 Modern Arm CPUs like Neoverse V2 support SIMD (Single Instruction, Multiple Data) extensions that allow processing multiple bytes in parallel. In this section, you'll explore how NEON and SVE vector instructions can dramatically accelerate bitmap scanning by skipping over large regions of unset data and reducing per-bit processing overhead.
 
-## NEON Implementation
+## NEON implementation
+
+This implementation uses NEON SIMD (Single Instruction, Multiple Data) instructions to process 16 bytes (128 bits) at a time, significantly accelerating the scanning process. 
+
+Copy the NEON implementation shown below into the same file:
 
-This implementation uses NEON SIMD (Single Instruction, Multiple Data) instructions to process 16 bytes (128 bits) at a time, significantly accelerating the scanning process. Copy the NEON implementation shown below into the same file:
 ```c
 // NEON implementation of bit vector scanning
 size_t scan_bitvector_neon(bitvector_t* bv, uint32_t* result_positions) {
@@ -83,9 +86,11 @@ size_t scan_bitvector_neon(bitvector_t* bv, uint32_t* result_positions) {
 ```
 This NEON implementation processes 16 bytes at a time with vector instructions. For sparse bitmaps, entire 16-byte chunks can be skipped at once, providing a significant speedup over byte-level skipping. After vector processing, it falls back to scalar code for any remaining bytes that don't fill a complete 16-byte chunk.
 
-## SVE Implementation
+## SVE implementation
+
+This implementation uses SVE instructions which are available in the Arm Neoverse V2 based AWS Graviton 4 processor. 
 
-This implementation uses SVE instructions which are available in the Arm Neoverse V2 based AWS Graviton 4 processor. Copy this SVE implementation into the same file:
+Copy this SVE implementation into the same file:
 
 ```c
 // SVE implementation using svcmp_u8, PNEXT, and LASTB
@@ -152,7 +157,7 @@ size_t scan_bitvector_sve2_pnext(bitvector_t* bv, uint32_t* result_positions) {
 ```
 The SVE implementation efficiently scans bitmaps by using `svcmpne_u8` to identify non-zero bytes and `svpnext_b8` to iterate through them sequentially. It extracts byte indices and values with `svlastb_u8`, then processes individual bits using scalar code. This hybrid vector-scalar approach maintains great performance across various bitmap densities. On Graviton4, SVE vectors are 128 bits (16 bytes), allowing processing of 16 bytes at once. 
 
-## Next up: Apply vectorized scanning to database workloads
+## Next up: apply vectorized scanning to database workloads
 
 With both NEON and SVE implementations in place, you’ve now unlocked the full power of Arm’s vector processing capabilities for bitmap scanning. These SIMD techniques allow you to process large bitvectors more efficiently—especially when filtering sparse datasets or skipping over large blocks of empty rows.
 

content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/05-benchmarking-and-results.md

@@ -40,7 +40,9 @@ double benchmark_scan(size_t (*scan_func)(bitvector_t*, uint32_t*),
 ```
 
 ## Main function
-The main function of your program is responsible for setting up the test environment, running the benchmarking code for the four different implementations across various bit densities, and reporting the results. In the context of bitmap scanning, bit density refers to the percentage or proportion of bits that are set (have a value of 1) in the bitmap. Copy the main function code below into `bitvector_scan_benchmark.c`:
+The main function of your program is responsible for setting up the test environment, running the benchmarking code for the four different implementations across various bit densities, and reporting the results. In the context of bitmap scanning, bit density refers to the percentage or proportion of bits that are set (have a value of 1) in the bitmap. 
+
+Copy the main function code below into `bitvector_scan_benchmark.c`:
 
 ```C
 int main() {
@@ -148,7 +150,7 @@ When running on a Graviton4 c8g.large instance with Ubuntu 24.04, the results sh
 | 0.0100  | 99,511   | 7.821          | 1.570            | 2.252 | 1.353      |
 | 0.1000  | 951,491  | 12.817         | 8.336            | 9.106 | 6.770      |
 
-### Speed-up vs generic Scalar
+### Speed-up vs generic scalar
 
 | Density | Scalar Optimized | NEON    | SVE        |
 |---------|------------------|---------|------------|
@@ -160,23 +162,25 @@ When running on a Graviton4 c8g.large instance with Ubuntu 24.04, the results sh
 
 ## Understanding the results
 
-## Generic Scalar vs Optimized Scalar
+The benchmarking results reveal how different bitmap scanning implementations perform across a range of bit densities—from completely empty vectors to those with millions of set bits. Understanding these trends is key to selecting the most effective approach for your specific use case.
+
+### Generic scalar vs optimized scalar
 
 The optimized scalar implementation shows significant improvements over the generic scalar implementation due to:
 
 * **Byte-level Skipping**: Avoiding processing empty bytes
 * **Reduced Function Calls**: Accessing bits directly rather than through function calls
 * **Better Cache Utilization**: More sequential memory access patterns
 
-## Optimized Scalar vs NEON
+### Optimized scalar vs NEON
 
 The NEON implementation shows further improvements over the optimized scalar implementation for sparse bit vectors due to:
 
 * **Chunk-level Skipping**: Quickly skipping 16 empty bytes at once
 * **Vectorized Comparison**: Checking multiple bytes in parallel
 * **Early Termination**: Quickly determining if a chunk contains any set bits
 
-## NEON vs SVE
+### NEON vs SVE
 
 The performance comparison between NEON and SVE depends on the bit density:
 
@@ -190,7 +194,7 @@ The performance comparison between NEON and SVE depends on the bit density:
    - SVE consistently outperforms NEON
    - SVE achieves up to 1.66x speedup over NEON at 0.01% density
 
-## Key Optimizations in SVE Implementation
+### Key optimizations in SVE implementation
 
 The SVE implementation includes several key optimizations:
 
@@ -204,7 +208,7 @@ The SVE implementation includes several key optimizations:
 
 * **Prefetching**: Using `__builtin_prefetch` to reduce memory latency by prefetching the next chunk of data.
 
-## Next up: Apply what you’ve learned to real-world workloads
+## Next up: apply what you’ve learned to real-world workloads
 
 Now that you’ve benchmarked all four bitmap scanning implementations—scalar (generic and optimized), NEON, and SVE—you have a data-driven understanding of how vectorization impacts performance across different bitmap densities.