Architectural Optimization of WebAssembly Transformer Hot Loops: Micro-Profiling, Scalar Optimizations, and Hardware-Accelerated SIMD for Quantized Llama Models

Full report

On this page

The rapid migration of large language model inference to client-side edge environments has shifted the focus of software engineering toward optimizing execution speed inside sandboxed browser runtimes.1 While high-level JavaScript frameworks enable rapid application development, they bring garbage collection pauses and dynamic just-in-time compilation changes that degrade performance.1 Achieving predictable execution speed for small models, such as TinyLlama, requires bypasses of these virtualization layers.1 Compiling a zero-dependency, "no-crate" Rust-to-WebAssembly transformer targeting standard linear memory environments (wasm32-unknown-unknown) forces software architects to optimize at the micro-architectural level.4 Operands must be packed tightly, memory boundaries statically defined, and vector operations mapped directly to hardware registers to prevent performance drop-offs.2 This report analyzes the computational limits of WebAssembly execution, evaluates block dequantization mechanics, details scalar-first optimizations in safe Rust, and outlines the performance of standard and relaxed SIMD vector lanes.2

WebAssembly Compilation Dynamics and Runtime Profiling

The execution of compiled WebAssembly inside modern browser engines, such as Google V8 or SpiderMonkey, relies on multi-tiered compilation pipelines.10 In V8, when a WebAssembly module is downloaded, the Liftoff baseline compiler converts the bytecode into machine code in a single pass to achieve near-instantaneous startup.10 While Liftoff compiles code quickly, the resulting binary executes without advanced global optimizations.10 To achieve maximum execution speed, the browser spawns background threads running the TurboFan optimizing compiler, which targets "hot loops" for global register allocation, loop unrolling, and inlining.3 Unlike JavaScript engines that rely on runtime type feedback to generate speculative native code, WebAssembly is statically typed, allowing TurboFan to generate optimized machine layouts without execution pauses.10 However, the transition from Liftoff to TurboFan creates transient warm-up phases, during which the first few forward passes of a transformer model can show elevated latency.10 This contrasts with native environments where compiled code runs immediately at peak performance.11 High-performance JS execution is prone to performance cliffs caused by sudden JIT cache evictions or allocation-driven garbage collection spikes, making WebAssembly the preferred target for predictable client-side deep learning.1

WebAssembly JIT Tiering Lifecycle:

│ ▼ (Eager Compile) ┌──────────────┐ (Asynchronous Background Trace) ┌──────────────┐ │ Liftoff JIT │ ────────────────────────────────────────\> │ TurboFan JIT │ │ (Low Opts) │ \<──────────────────────────────────────── │ (Optimized) │ └──────────────┘ (Runtime Loop Warm-up) └──────────────┘

Accurately profiling these hot execution loops within a sandboxed runtime requires careful management of the observer effect.12 Instrumenting a WebAssembly binary by injecting entry and exit timing markers (using parsing libraries such as wasmparser, wasm-encoder, or wasmprinter) introduces significant instruction overhead.12 In tight loops, such as matrix-vector dot products, the execution cost of retrieving high-resolution system timestamps and manipulating string buffers often exceeds the cost of the arithmetic operations being profiled.12 This skew alters the JIT compiler’s register allocation and prevents the inlining of critical short functions.6 To limit this diagnostic overhead to acceptable ranges (typically under three percent), profiling tools must restrict instrumentation to coarse-grained block boundaries, or rely on asynchronous CPU sampling runtimes that poll the execution stack.10

Block-Quantization Formats and Execution Bottlenecks

Autoregressive transformer inference is fundamentally limited by memory bandwidth.13 During the generation of each new token, the entire weight tensor of the model must be loaded from system memory to compute multiplications against the current query vector.13 To reduce memory requirements and accelerate inference on consumer CPUs, weights are quantized into block-compressed formats.2 The standard formats supported by edge inference runtimes are classified into three architectural tiers:

• Basic Quantization: Traditional formats, such as Q4\_0 and Q8\_0, segment weight tensors into small, independent blocks of [Figure omitted from source export] values.2 These formats are symmetric and represent weights using a single scale factor and packed low-precision integers.2
• K-Quants: Advanced multi-level formats, such as Q4\_K and Q6\_K, organize weights into large super-blocks of 256 values, subdivided into 16 smaller blocks of 16 values.2 Scales are compressed using a secondary super-block scaling factor to minimize metadata overhead.2
• I-Quants: High-density vector quantization formats that encode small groups of weights (typically groups of eight) as indices pointing to a static codebook of reference multidimensional vectors.

Within symmetric block structures, such as Q4\_0, the original 32-bit floating-point weights ([Figure omitted from source export]) are recovered from the packed 4-bit signed integers ([Figure omitted from source export]) by multiplying them by the block scale factor ([Figure omitted from source export]), expressed as: $$w\_i \= q\_i \\cdot d \\quad \\text{for} \\quad i \\in $$ In the Q8\_0 format, weights are represented as signed 8-bit integers ([Figure omitted from source export]) multiplied by the scale factor.16 This maintains higher numerical precision and avoids the destabilizing calibration issues often seen in sub-8-bit systems.2

During execution, a naive implementation of matrix-vector multiplication ([Figure omitted from source export]) introduces significant bottlenecks.17 If the runtime dequantizes quantized weights back into an intermediate 32-bit floating-point tensor before performing standard operations, the CPU encounters high memory traffic.17 The cost of executing bit-masks, shifts, and float conversions to unpack low-precision weights can exceed the cost of the floating-point multiplication itself.17 Additionally, if cache locality is lost during the dequantization pass, CPU execution units stall while waiting for main memory access, negating the benefits of quantization.17

Scalar-First Optimization Paradigms in No-Crate Rust

Before leveraging hardware-specific vector lanes, major performance gains must be achieved by optimizing scalar code.9 In a zero-dependency Rust environment compiled for wasm32-unknown-unknown, safety checks and memory management models directly impact the quality of the generated assembly.5

Bounds Check Elision

By default, the Rust compiler inserts runtime checks on every array or slice indexing operation (slice\[i\]) to guarantee memory safety.9 If an index falls outside the boundaries of the slice, the runtime executes a panicking sequence.9 Inside a transformer's matrix multiplication loop, these bounds checks add branching instructions that disrupt instruction pipelining and prevent loop vectorization.9 To elide these bounds checks without using unsafe blocks, system architects structure code using pattern-matching techniques that allow the LLVM compiler to prove bounds violations are impossible.9 Three safe optimization patterns are effective for loop elision:

Rust // Pattern 1: Assertion Hoisting // Forcing a single check at the input boundary allows LLVM to optimize the loop body. pub fn dot\_product\_hoisted(activation: &\[f32\], weights: &\[f32\]) \-\> f32 { let len \= activation.len(); assert\!(weights.len() \>= len); // Asserting once at the boundary elides inner checks let mut accumulator \= 0.0; for i in 0..len { accumulator \+= activation\[i\] \* weights\[i\]; // No bounds checks generated in this loop body } accumulator }

// Pattern 2: Pre-Slicing // Slicing to a known compile-time size guarantees bounds compliance. pub fn process\_block\_pre\_sliced(activation: &\[f32\], weights: &\[f32\]) \-\> f32 { let act\_slice \= \&activation\[..32\]; // Fixed slice asserts the length is at least 32 \[20\] let weight\_slice \= \&weights\[..32\]; let mut accumulator \= 0.0; for i in 0..32 { accumulator \+= act\_slice\[i\] \* weight\_slice\[i\]; // Fully elides bounds checking \[20\] } accumulator }

// Pattern 3: Relative Reverse Indexing // Writing elements in reverse index order allows a single high-index check to validate lower offsets. pub fn reverse\_indexing\_accumulator(input: &\[f32\]) \-\> f32 { let c \= input; // Accessing the maximum offset first establishes the safety boundary \[22\] let b \= input; // Subsequent lower offsets require no additional bounds checks \[22\] let a \= input; a \+ b \+ c }

The alternative is the unsafe escape hatch provided by get\_unchecked and get\_unchecked\_mut.9 These methods generate direct memory dereferences, bypassing runtime safety checks.11 While this matches native execution speeds, it carries a severe penalty if an out-of-bounds access occurs.11 Rather than raising a typical native segmentation fault, WebAssembly runtimes will trap, halting execution of the sandbox environment and corrupting memory state.11 Safe assertion hoisting and pre-slicing should therefore be used wherever possible.9

Allocation-Free Runtimes and Alternative Kernels

WebAssembly environments do not have the complex dynamic memory runtimes of native desktop operating systems.1 The default allocator for wasm32-unknown-unknown (typically dlmalloc) is lightweight and can suffer from heap fragmentation when subjected to rapid allocation cycles.5 Instantiating dynamic vectors (Vec) or expanding activation maps inside the generation loop triggers repetitive memory allocations, causing execution stalls and garbage collection overhead in the host browser.1 To prevent this, the entire transformer context—including intermediate layers, attention weights, and key-value caches—must be mapped to static, pre-allocated memory slices during module initialization.2 For low-memory deployment targets, alternative pure-Rust runtimes such as picolm use a virtual memory management strategy.24 By streaming model layers sequentially and releasing processed pages back to the host system using virtual memory commands (specifically madvise(DONTNEED)), the peak memory footprint is constrained to the size of a single layer ([Figure omitted from source export]) rather than the size of the entire model ([Figure omitted from source export]).24 This allows larger models to run within restricted environments like secure sandboxes or enclave runtimes.24 To avoid the memory traffic associated with decompressing block-quantized formats into floating-point buffers, optimized runtimes implement fused dequantize-and-dot kernels.17 These kernels unpack compressed weights and multiply them with activation vectors in a single step, keeping intermediate values in CPU registers.17

WebAssembly SIMD Lanes: Standard vs. Relaxed Instructions

When scalar optimization reaches its limit, additional speedups require instruction-level data parallelism.7 WebAssembly provides vector acceleration through the simd128 instruction set, introducing a 128-bit vector register (v128) that operates on multiple lanes simultaneously.26 To compile a Rust module to target WebAssembly SIMD lanes, specific target flags must be passed to the compiler:

Bash RUSTFLAGS="-C target-feature=+simd128" cargo build \--target wasm32-unknown-unknown \--release

When using intrinsics from core::arch::wasm32, compiling functions with \#\[inline(always)\] is critical.6 WebAssembly lacks the register-remapping flexibility of native CPUs.6 If the compiler does not inline a SIMD intrinsic, it generates a full WebAssembly function call stack for a single instruction, creating overhead that can make vector execution slower than scalar code.6

Standard SIMD128 Dot Products

Standard SIMD execution relies on explicit widening multiply-extend operations.29 To perform dot products on 8-bit quantized weights and 8-bit activation vectors, standard WebAssembly SIMD uses a sequence of widening and addition operations 29:

1. Loading 8-bit signed values into v128 vector registers.28
2. Performing widening multiplications: i16x8.extmul\_low\_i8x16\_s and i16x8.extmul\_high\_i8x16\_s widen signed 8-bit values to 16-bit intermediate lanes to prevent numerical overflow.29
3. Summing adjacent pairs of values into 32-bit integer lanes using i32x4.dot\_i16x8\_s.29
4. Accumulating the 32-bit integers into the final accumulator.30

This emulation path requires multiple cycles and increases register pressure, as multiple intermediate registers must be kept alive to process the widening steps.32

Rust // Standard SIMD128 widening dot product \#\[inline(always)\] pub unsafe fn standard\_simd128\_dot\_accumulate(a: v128, b: v128) \-\> v128 { // Widen low and high halves from 8-bit to 16-bit integers let low\_half \= i16x8\_extmul\_low\_i8x16\_s(a, b); // let high\_half \= i16x8\_extmul\_high\_i8x16\_s(a, b); //

// Pairwise multiply and accumulate into 32-bit registers let acc\_low \= i32x4\_dot\_i16x8\_s(low\_half); // \[33, 34\] let acc\_high \= i32x4\_dot\_i16x8\_s(high\_half); // \[33, 34\]

i32x4\_add(acc\_low, acc\_high) // \[30\] }

Next-Generation Relaxed SIMD

The WebAssembly Relaxed SIMD proposal addresses these limitations by introducing instructions that yield highly optimized, platform-dependent behavior.8 By allowing local non-determinism—where the exact output or NaN handling can vary slightly based on the host hardware—the WebAssembly compiler can map vector operations directly to the native instructions of modern CPU architectures.35 To compile targeting relaxed SIMD, compile flags must enable relaxed vector operations:

Bash RUSTFLAGS="-C target-feature=+relaxed-simd" cargo build \--target wasm32-unknown-unknown \--release

The core optimization for quantized transformer models is the instruction wasm\_i32x4\_relaxed\_dot\_i8x16\_i7x16\_add (emitted as i32x4.relaxed\_dot\_i8x16\_i7x16\_add\_s in bytecode).8 This instruction optimizes quantized matrix-vector calculations by performing sign-extension, element-wise multiplication, and accumulation in a single step.8 The instruction accepts three vector operands:

• Vector a (v128 of i8x16): Represents 16 signed activation values.32
• Vector b (v128 of i8x16 interpreted as 7-bit values): Represents 16 quantized weights, constrained to a 7-bit range to prevent signed overflow during accumulation.32
• Vector c (v128 of i32x4): The target accumulator register containing 4 lanes of signed 32-bit integers.32

Mathematically, the operation performs a 4-lane dot product with accumulation: $$y\_i \= c\_i \+ \\sum\_{k=0}^{3} a\_{4i+k} \\cdot b\_{4i+k} \\quad \\text{for} \\quad i \\in $$ This single WebAssembly instruction maps directly to native hardware acceleration blocks across different CPU architectures:

This optimization path was developed through community efforts (such as llama.cpp pull request \#19590, building on foundational work by ngxson in the wllama repository and suggestions from camel-cdr).8 Integrating these relaxed dot-product instructions into client-side runtimes provides significant speedups, making browser-based WebAssembly engines highly competitive with native execution paths.8

Rust // Fused dot product accumulation utilizing Relaxed SIMD intrinsics \#\[cfg(target\_arch \= "wasm32")\] \#\[target\_feature(enable \= "relaxed-simd")\] pub unsafe fn relaxed\_simd\_dot\_accumulate( activation: &\[i8\], weights: &\[i8\], accumulator: &mut \[i32; 4\] ) { // Load 16 bytes (128 bits) of activations and weights into registers let vec\_act \= v128\_load(activation.as\_ptr() as \const v128); // \[28\] let vec\_weight \= v128\_load(weights.as\_ptr() as \const v128); // \[28\]

// Load current 32-bit accumulator states let vec\_accum \= v128\_load(accumulator.as\_ptr() as \*const v128);

// Perform the fused dot product accumulation step let result \= i32x4\_relaxed\_dot\_i8x16\_i7x16\_add(vec\_act, vec\_weight, vec\_accum); // \[35, 37, 38\]

// Write back the updated states to the accumulator v128\_store(accumulator.as\_mut\_ptr() as \*mut v128, result); }

Architectural Evaluation and Execution Trade-Offs

Evaluating different runtime engines, compilation settings, and hardware targets reveals how optimization choices affect prompt evaluation and token generation speeds:

Analyzing these execution pathways reveals several key insights:

• Memory Access Overheads: Traditional implementations, such as unoptimized Candle runtimes without bulk dequantization flags enabled, run slower when processing quantized weights compared to unquantized float values.19 This is due to the overhead of unpacking block-level scales during element-wise loop execution.19 Setting bulk decompression flags (such as CANDLE\_DEQUANTIZE\_ALL) addresses this bottleneck at the cost of higher memory usage, transforming memory-bound execution bottlenecks into raw computation limits.19
• WebGPU Trade-offs: WebGPU-based runtimes like LlamaWeb show excellent token generation (decode) speeds by processing matrix-vector operations on GPU execution units. However, during the prompt evaluation (prefill) phase, WebGPU backends can underperform optimized CPU implementations. This is due to the latency associated with synchronizing memory between the CPU host and GPU buffers, illustrating the trade-off between parallel execution scaling and platform transfer overheads.
• Impact of Relaxed SIMD: Combining relaxed SIMD instructions with static pre-allocation yields performance close to native execution runtimes.8 By mapping the core matrix loops directly to hardware instructions (such as SDOT on ARM or VPMADDUBSW on x86-64), the browser's JIT compiler bypasses the emulated instructions of standard WASM, leading to significant speedups on modern consumer hardware.8

Architectural Conclusions and Implementation Guidelines

To build a high-performance, zero-dependency Rust-to-WebAssembly transformer engine that operates efficiently within browser environments, development should follow three clear architectural principles:

• Implement Zero-Allocation Memory Schemes: Avoid dynamic heap allocations inside the autoregressive execution loop.1 All required buffers—including key-value caches, intermediate activation states, attention matrices, and projection buffers—must be allocated as a single, contiguous linear memory block at startup.2 Functions should accept mutable references to pre-allocated buffers rather than allocating new structures during execution.2
• Prioritize Safe Compiler-Proven Loop Elision: Avoid using unsafe blocks to bypass safety checks.9 Structure loops using explicit pattern matching, fixed-size slice indexing, and assertion hoisting.20 This allows the LLVM compiler to statically prove bounds compliance, eliding bounds checks safely while enabling automatic loop optimization.9
• Deploy Runtime-Detected Vector Pipelines: Implement a multi-build deployment pipeline.7 Use feature detection (via libraries like wasm-feature-detect) at runtime to load the most optimized WebAssembly module supported by the client browser 7:

1. Relaxed SIMD Build: Target modern browsers running on ARMv8.2+ or AVX2-compatible x86-64 hardware, utilizing wasm\_i32x4\_relaxed\_dot\_i8x16\_i7x16\_add instructions to maximize performance.8
2. Standard SIMD128 Build: Target older, SIMD-compliant browsers using standard vector instructions.7
3. Scalar Fallback Build: Target legacy or restricted environments, using pre-sliced, optimized scalar loops to ensure compatibility.7

Applying these strategies allows developers to build client-side WebAssembly transformers that execute with high, predictable throughput, enabling local AI inference directly within the browser sandbox.1

Works cited

1. \[Project\] Running quantized BERT in the browser via WebAssembly (Rust \+ Candle) for local Semantic Search : r/LocalLLaMA \- Reddit, accessed June 29, 2026, https://www.reddit.com/r/LocalLLaMA/comments/1q9j0r8/project\_running\_quantized\_bert\_in\_the\_browser\_via/
2. Llamas on the Web: Memory-Efficient, Performance-Portable, and Multi-Precision LLM Inference with WebGPU \- arXiv, accessed June 29, 2026, https://arxiv.org/html/2605.20706v1
3. Maybe you don't need Rust and WASM to speed up your JS (2018) | Hacker News, accessed June 29, 2026, https://news.ycombinator.com/item?id=27616656
4. Running LLMs on CPUs with Rust from scratch: Llama 3.2, PHI 3.5, and Gemma 2 \- Reddit, accessed June 29, 2026, https://www.reddit.com/r/rust/comments/1g3w05g/running\_llms\_on\_cpus\_with\_rust\_from\_scratch\_llama/
5. wasm32-unknown-unknown \- The rustc book \- Rust Documentation, accessed June 29, 2026, https://doc.rust-lang.org/rustc/platform-support/wasm32-unknown-unknown.html
6. rten\_simd \- Rust \- Docs.rs, accessed June 29, 2026, https://docs.rs/rten-simd
7. Fast, parallel applications with WebAssembly SIMD \- V8 JavaScript engine, accessed June 29, 2026, https://v8.dev/features/simd
8. WASM Relaxed SIMD Enhancement by JeremyCEY · Pull Request ..., accessed June 29, 2026, https://github.com/ggml-org/llama.cpp/pull/19590
9. How to avoid bounds checks in Rust (without unsafe\!) | by Sergey "Shnatsel" Davidoff, accessed June 29, 2026, https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-rust-without-unsafe-f65e618b4c1e
10. Liftoff: a new baseline compiler for WebAssembly in V8, accessed June 29, 2026, https://v8.dev/blog/liftoff
11. WASM faster than native x86-64 build. WT..?\! \- Page 2 \- The Rust Programming Language Forum, accessed June 29, 2026, https://users.rust-lang.org/t/wasm-faster-than-native-x86-64-build-wt/31171?page=2
12. WASM Performance Analysis \- Instrumentation Solution \- Alibaba Cloud Community, accessed June 29, 2026, https://www.alibabacloud.com/blog/wasm-performance-profiling---instrumentation-solution\_602049
13. LLaMA Now Goes Faster on CPUs, accessed June 29, 2026, https://justine.lol/matmul/
14. Madreag/turbo3-cuda: LLM inference in C/C++ \- GitHub, accessed June 29, 2026, https://github.com/Madreag/turbo3-cuda
15. On-Device Inference Engine from Scratch using Rust — Layer 1: The GGUF Loader | by Karthikeyan Sukumaran | Medium, accessed June 29, 2026, https://medium.com/@karthikworks/layer-1-the-gguf-loader-e81e6ce4170a
16. Optimize Llama.cpp with Arm I8MM instruction \- Arm Developer, accessed June 29, 2026, https://developer.arm.com/community/arm-community-blogs/b/ai-blog/posts/optimize-llama-cpp-with-arm-i8mm-instruction
17. Support for quantisation · Issue \#359 · huggingface/candle \- GitHub, accessed June 29, 2026, https://github.com/huggingface/candle/issues/359
18. candle/candle-core/src/quantized/k\_quants.rs at main \- GitHub, accessed June 29, 2026, https://github.com/huggingface/candle/blob/main/candle-core/src/quantized/k\_quants.rs
19. Any tips to speed up quantized Whisper inference on Android? · Issue \#1048 · huggingface/candle \- GitHub, accessed June 29, 2026, https://github.com/huggingface/candle/issues/1048
20. What is the overhead impact of array's bounds checking? : r/rust \- Reddit, accessed June 29, 2026, https://www.reddit.com/r/rust/comments/7rz1bx/what\_is\_the\_overhead\_impact\_of\_arrays\_bounds/
21. If you don't need to do bounds checking, and doing it anyway, then that's a step... | Hacker News, accessed June 29, 2026, https://news.ycombinator.com/item?id=39538617
22. How to avoid bounds checks in Rust (without unsafe\!) \- Reddit, accessed June 29, 2026, https://www.reddit.com/r/rust/comments/10edmjf/how\_to\_avoid\_bounds\_checks\_in\_rust\_without\_unsafe/
23. Rust is just a tool | Hacker News, accessed June 29, 2026, https://news.ycombinator.com/item?id=47190947
24. a3s-power \- crates.io: Rust Package Registry, accessed June 29, 2026, https://crates.io/crates/a3s-power
25. DeepSeek-R1 optimizes the llama.cpp WASM runtime by leveraging SIMD instructions \-x2 Speed Increase \- the whole PR is 99% R1 : r/singularity \- Reddit, accessed June 29, 2026, https://www.reddit.com/r/singularity/comments/1ibew93/deepseekr1\_optimizes\_the\_llamacpp\_wasm\_runtime\_by/
26. core::arch::wasm32 \- Rust, accessed June 29, 2026, https://doc.rust-lang.org/beta/core/arch/wasm32/index.html
27. Tracking issue for WebAssembly SIMD support · Issue \#74372 · rust-lang/rust \- GitHub, accessed June 29, 2026, https://github.com/rust-lang/rust/issues/74372
28. v128 in core::arch::wasm32 \- Rust, accessed June 29, 2026, https://public-docs.ferrocene.dev/main//core/arch/wasm32/struct.v128.html
29. WebAssembly SIMD-specific arithmetic instructions \- MDN Web Docs \- Mozilla, accessed June 29, 2026, https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/SIMD/arithmetic
30. spec/proposals/simd/SIMD.md at main · WebAssembly/spec \- GitHub, accessed June 29, 2026, https://github.com/WebAssembly/spec/blob/main/proposals/simd/SIMD.md
31. narrow\_i16x8\_u: Wasm SIMD conversion instruction \- WebAssembly \- MDN Web Docs, accessed June 29, 2026, https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/SIMD/conversion/narrow\_i16x8\_u
32. Relaxed Integer Dot Product instructions · Issue \#52 · WebAssembly/relaxed-simd \- GitHub, accessed June 29, 2026, https://github.com/WebAssembly/relaxed-simd/issues/52
33. dot\_i16x8\_s: Wasm SIMD arithmetic instruction \- WebAssembly \- MDN Web Docs, accessed June 29, 2026, https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/SIMD/arithmetic/dot\_i16x8\_s
34. relaxed-simd/proposals/relaxed-simd/Overview.md at main \- GitHub, accessed June 29, 2026, https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md
35. Intent to Ship: WebAssembly Relaxed SIMD, accessed June 29, 2026, https://groups.google.com/a/chromium.org/g/blink-dev/c/HzLlEGLSx7E
36. llvm-project/clang/lib/Headers/wasm\_simd128.h at main \- GitHub, accessed June 29, 2026, https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/wasm\_simd128.h
37. oxillama\_wasm \- Rust \- Docs.rs, accessed June 29, 2026, https://docs.rs/oxillama-wasm
38. huggingface/candle: Minimalist ML framework for Rust \- GitHub, accessed June 29, 2026, https://github.com/huggingface/candle
39. TheTom/llama-cpp-turboquant: LLM inference in C/C++ \- GitHub, accessed June 29, 2026, https://github.com/TheTom/llama-cpp-turboquant