Java vs CPU
summary
Three Java experiments show how low-level CPU details affect performance: reordering three nested loops to improve memory locality and cache-line use drops runtime from 8s to 0.5s (perf shows 0.56 vs 1.79 instructions/cycle). Multithreaded counters suffer false sharing—changing from one atomic counter to per-thread ints moves runtime from 600ms to 500ms with only modest scaling. JIT can auto-vectorize, but inspecting assembly and using perf/toplev/VTune reveals that using the SIMD Vector API or tuning data layout gives the largest throughput gains (GB/s-level improvements).
AI-written summary · about
chapters (10)
- 0:00Introduction
- 2:34Complexity vs performance
- 5:03CPU memory interaction
- 9:59Parallelism in multithreading
- 15:38True vs false cache sharing
- 18:06JVM performance
- 20:52LinkedList vs ArrayList
- 25:03Vector instructions impact
- 30:17Summary
- 33:24Q&A
related talks
51mJava vs CPU — round 2
51mJava at Speed: Getting the Most Out of Modern Hardware
43mHow to make your electrons do more in Java?
40mHow to make your electrons do more in Java
48mJust-In-Time Compilation for Java Performance: Recent and Ongoing Improvements
47mMicrobenchmarks performance in the smaller scale
54mWhat Lies Beneath
54mJava performance techniques The cost of HotSpot runtime optimizations