How NOT To Program an Out-of-order Vector Processor
summary
Benchmarks on two RVV-capable designs compare handcrafted and compiler-vectorized code and show concrete wins and failures: using strip mining usually improves throughput (removing VL-based strip mining causes up to ~10x slowdown on an in-order core due to register spillage), while out-of-order hardware hides those costs and prefers strip-mined loops. Tests of VR gather, vcompress and segmented loads/stores give break-even Elms (elements per vector) where complex ops beat scalar sequences; auto-vectorized GCC improves SPEC2006 and a vectorized Doom demo shows ~5x FPS vs scalar and another ~5x vs an in-order vector core.
AI-written summary · about
chapters (4)
related talks
17mThe Real Challenge for RISC-V Vector Processors
20mEnhance the Performance of QEMU RVV Load/Store Implementation
23mBeating the Benchmarks: Co-evolving the ISA and Development Tools
56mWrite Fast Code Like a Native
45mHackathon Presentations
43mWhat Every Programmer Should Know about How CPUs Work
29mReal Programming
11mDemo: Andes ACE: Enabling Custom RISCV Instructions Safely