updates

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/01-introduction.md

@@ -23,18 +23,18 @@ Bitmap scanning involves searching through a bit vector to find positions where
 
 In database systems, bitmaps are commonly used to represent:
 
-* **Bitmap Indexes**: each bit represents whether a row satisfies a particular condition
-* **Bloom Filters**: probabilistic data structures used to test set membership
-* **Column Filters**: bit vectors indicating which rows match certain predicates
+* **Bitmap indexes**: each bit represents whether a row satisfies a particular condition
+* **Bloom filters**: probabilistic data structures used to test set membership
+* **Column filters**: bit vectors indicating which rows match certain predicates
 
 The operation of scanning a bitmap to find set bits is often in the critical path of query execution, making it a prime candidate for optimization.
 
 ## The evolution of vector processing for bitmap scanning
 
 Here's how vector processing has evolved to improve bitmap scanning performance:
 
-* **Generic Scalar Processing**: traditional bit-by-bit processing with conditional branches
-* **Optimized Scalar Processing**: byte-level skipping to avoid processing empty bytes
+* **Generic scalar processing**: traditional bit-by-bit processing with conditional branches
+* **Optimized scalar processing**: byte-level skipping to avoid processing empty bytes
 * **NEON**: fixed-width 128-bit SIMD processing with vector operations
 * **SVE**: scalable vector processing with predication and specialized instructions like MATCH 
 
@@ -61,6 +61,6 @@ Create a directory for your implementations:
 mkdir -p bitmap_scan
 cd bitmap_scan
 ```
-## Next steps
 
-In the next section, you’ll define the core bitmap data structure and utility functions for setting, clearing, and inspecting bits.
+## Next up: build the bitmap scanning foundation
+With your development environment set up, you're ready to dive into the core of bitmap scanning. In the next section, you’ll define a minimal bitmap data structure and implement utility functions to set, clear, and inspect individual bits.

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

@@ -83,4 +83,6 @@ size_t bitvector_count_scalar(bitvector_t* bv) {
 }
 ```
 
-You now have a functional, compact bit vector in C for testing bitmap scanning performance. Next, you'll implement scalar, NEON, and SVE-based scanning routines that operate on this structure.
+## 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,14 @@ 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 steps
+## Next up: Accelerate bitmap scanning with NEON and SVE
 
-Next, you’ll explore how to accelerate bitmap scanning using NEON and SVE SIMD instructions on Arm Neoverse platforms like Graviton4, comparing them directly to these scalar baselines.
+You’ve now implemented two scalar scanning routines:
 
+* A generic per-bit loop for correctness and simplicity
+
+* An optimized scalar version that improves performance using byte-level skipping
+
+These provide a solid foundation and performance baseline—but scalar methods can only take you so far. To unlock real throughput gains, it’s time to leverage SIMD (Single Instruction, Multiple Data) execution.
+
+In the next section, you’ll explore how to use Arm NEON and SVE vector instructions to accelerate bitmap scanning. These approaches will process multiple bytes at once and significantly outperform scalar loops—especially on modern Arm-based CPUs like AWS Graviton4.

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

@@ -152,3 +152,8 @@ 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
+
+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.
+
+In the next section, you’ll learn how to apply these optimizations in the context of real database operations like bitmap index scans, Bloom filter probes, and column filtering. You’ll also explore best practices for selecting the right implementation based on bit density, and tuning for maximum performance on AWS Graviton4.

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

@@ -164,45 +164,58 @@ When running on a Graviton4 c8g.large instance with Ubuntu 24.04, the results sh
 
 The optimized scalar implementation shows significant improvements over the generic scalar implementation due to:
 
-1. **Byte-level Skipping**: Avoiding processing empty bytes
-2. **Reduced Function Calls**: Accessing bits directly rather than through function calls
-3. **Better Cache Utilization**: More sequential memory access patterns
+* **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
 
 The NEON implementation shows further improvements over the optimized scalar implementation for sparse bit vectors due to:
 
-1. **Chunk-level Skipping**: Quickly skipping 16 empty bytes at once
-2. **Vectorized Comparison**: Checking multiple bytes in parallel
-3. **Early Termination**: Quickly determining if a chunk contains any set bits
+* **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
 
 The performance comparison between NEON and SVE depends on the bit density:
 
-1. **Very Sparse Bit Vectors (0% - 0.01% density)**:
+*  **Very Sparse Bit Vectors (0% - 0.01% density)**:
    - NEON performs better for empty bitvectors due to lower overhead
    - NEON achieves up to 127.41x speedup over generic scalar
    - SVE performs better for very sparse bitvectors (0.001% density)
    - SVE achieves up to 29.07x speedup over generic scalar at 0.001% density
 
-2. **Higher Density Bit Vectors (0.1% - 10% density)**:
+* **Higher Density Bit Vectors (0.1% - 10% density)**:
    - SVE consistently outperforms NEON
    - SVE achieves up to 1.66x speedup over NEON at 0.01% density
 
 ## Key Optimizations in SVE Implementation
 
 The SVE implementation includes several key optimizations:
 
-1. **Efficient Non-Zero Byte Detection**: Using `svcmpne_u8` to quickly identify non-zero bytes in the bitvector.
+* **Efficient Non-Zero Byte Detection**: Using `svcmpne_u8` to quickly identify non-zero bytes in the bitvector.
 
-2. **Byte-Level Processing**: Using `svpnext_b8` to efficiently find the next non-zero byte without processing zero bytes.
+* **Byte-Level Processing**: Using `svpnext_b8` to efficiently find the next non-zero byte without processing zero bytes.
 
-3. **Value Extraction**: Using `svlastb_u8` to extract both the index and value of non-zero bytes.
+* **Value Extraction**: Using `svlastb_u8` to extract both the index and value of non-zero bytes.
 
-4. **Hybrid Vector-Scalar Approach**: Combining vector operations for finding non-zero bytes with scalar operations for processing individual bits.
+* **Hybrid Vector-Scalar Approach**: Combining vector operations for finding non-zero bytes with scalar operations for processing individual bits.
 
-5. **Prefetching**: Using `__builtin_prefetch` to reduce memory latency by prefetching the next chunk of data.
+* **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
+
+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.
+
+In the next section, you’ll explore how to apply these techniques in real-world database workloads, including:
+
+* Bitmap index scans
+
+* Bloom filter checks
+
+* Column-level filtering in analytical queries
+
+You’ll also learn practical guidelines for choosing the right implementation based on bit density, and discover optimization tips that go beyond the code to help you get the most out of Arm-based systems like Graviton4.
 
 

content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/06-application-and-best-practices.md

@@ -25,23 +25,26 @@ Columnar databases frequently use bitmap filters to track which rows satisfy fil
 
 Based on the benchmark results, here are some best practices for optimizing bitmap scanning operations:
 
-1. **Choose the right implementation based on the expected bit density**:
+* Choose the right implementation based on the expected bit density**:
    - For empty bit vectors: NEON is optimal
    - For very sparse bit vectors (0.001% - 0.1% set bits): SVE is optimal due to efficient skipping
    - For medium to high densities (> 0.1% density): SVE still outperforms NEON
 
-2. **Implement Early Termination**: Always include a fast path for the no-hits case, as this can provide dramatic performance improvements.
+* Implement Early Termination**: Always include a fast path for the no-hits case, as this can provide dramatic performance improvements.
 
-3. **Use Byte-level Skipping**: Even in scalar implementations, skipping empty bytes can provide significant performance improvements.
+* Use Byte-level Skipping**: Even in scalar implementations, skipping empty bytes can provide significant performance improvements.
 
-4. **Consider Memory Access Patterns**: Optimize memory access patterns to improve cache utilization.
+* Consider Memory Access Patterns**: Optimize memory access patterns to improve cache utilization.
 
-5. **Leverage Vector Instructions**: Use NEON or SVE/SVE2 instructions to process multiple bytes in parallel.
+* Leverage Vector Instructions**: Use NEON or SVE/SVE2 instructions to process multiple bytes in parallel.
 
 ## Conclusion
 
-The SVE instructions provides a powerful way to accelerate bitmap scanning operations in database systems. By implementing these optimizations on Graviton4 instances, you can achieve significant performance improvements for your database workloads.
+Scalable Vector Extension (SVE) instructions provide a powerful and portable way to accelerate bitmap scanning in modern database systems. When implemented on Arm Neoverse V2–based servers like AWS Graviton4, they deliver substantial performance improvements across a wide range of bit densities.
+
+The SVE implementation shows particularly impressive performance for sparse bitvectors (0.001% - 0.1% density), where it outperforms both scalar and NEON implementations. For higher densities, it maintains a performance advantage by amortizing scan costs across wider vectors.
+
+These performance improvements can translate directly to faster query execution times, especially for analytical workloads that involve multiple bitmap operations.
+
 
-The SVE implementation shows particularly impressive performance for sparse bitvectors (0.001% - 0.1% density), where it outperforms both scalar and NEON implementations. For higher densities, it continues to provide substantial speedups over traditional approaches.
 
-These performance improvements can translate directly to faster query execution times, especially for analytical workloads that involve multiple bitmap operations.