Low-level acceleration

WASM SIMD and threaded PDF engine loader

Detect browser hardware features, choose the fastest compatible WASM core, and keep a safe fallback path for devices without cross-origin isolation or SIMD.

Runtime selector

WASM SIMD / pthread loader

The browser is probed first. If SIMD and thread isolation are available, the loader chooses thepdf-core.simd-threaded.wasmbuild. Otherwise it falls back to SIMD single-thread or baseline WASM.

Compiler flags for the real native core

emcc src/pdf_core.cpp \
  -O3 -flto -msimd128 -pthread \
  -s USE_PTHREADS=1 \
  -s PTHREAD_POOL_SIZE=navigator.hardwareConcurrency \
  -s ALLOW_MEMORY_GROWTH=1 \
  -s MODULARIZE=1 -s EXPORT_ES6=1 \
  -o public/wasm/pdf-core.simd-threaded.js

Feature detection and benchmarks run locally in this browser.

User guide

How to use WASM Accelerator Diagnostics

Detect WebAssembly SIMD, shared-memory thread prerequisites, and select an available core build.

1
Open the diagnostics page in a secure context.
2
Run SIMD, SharedArrayBuffer, and cross-origin-isolation checks.
3
Load the compatible baseline or optimized WASM core.
4
Run the included smoke benchmark and review results.

Best for

Validating deployment headers
Choosing baseline versus SIMD/thread builds

Important limitation

This is a loader and benchmark boundary, not a complete PDF compression engine. SIMD maps to platform vector instructions through the browser, not directly to a guaranteed AVX/NEON instruction.

Frequently asked questions

Why are threads unavailable?

SharedArrayBuffer generally requires HTTPS plus COOP and COEP headers.

Will SIMD always be faster?

No. Performance depends on workload, browser, device, and memory behavior.

PDFPerch processes files locally unless this guide explicitly identifies a cloud-dependent feature. Always keep an original copy and verify critical output before submission, printing, signing, or accounting use.