KitBench

KitBench is a straightforward Android benchmark that measures real CPU and memory performance — no synthetic tricks or hidden formulas. KEY FEATURES • Open methodology. The app shows the exact algorithms and pseudocode used in each test. • CPU, FPU, NEON & native ALU. Separate tests for integer (JVM/ART), floating-point (JVM), native ALU and SIMD/NEON — each in single-thread and multi-thread modes. • RAM bandwidth. Measures large-buffer copy throughput with cache-aware safeguards. • Memory latency (LAT). Pointer-chasing over a ring of 64-B nodes; L1 and DRAM presets; results in ns per dependent load. • Thermals & throttling. Temperature readouts and a “Throttling (~NN%)” badge; in Run all the app cools down to < 65 °C before each test. • Repeatable results. Fixed durations, consistent buffer sizes and clear units (ops/s, GB/s). • Private by design. No accounts, no ads, no analytics — everything runs locally. • Fast & lightweight. Minimal UI, instant start, no unnecessary permissions. • Modern device support. Works on ARM devices; uses NEON/ASM where available. HOW IT WORKS KitBench runs standardized loops directly on your device: • CPU tests: integer & floating-point math, logic and array access, with separate single-core and multi-core runs. • RAM test: large-buffer copy to measure effective bandwidth while reducing unrealistic cache effects. SCORING METHODOLOGY • Domains: ST (single-thread), MT (multi-thread), BW (RAM bandwidth), LAT (memory latency). Each domain is a geometric mean of normalized sub-tests. • Normalization: value/ref for higher-is-better (CPU/FPU/ASM/NEON, BW) and ref/value for lower-is-better (LAT). • Reference anchors (ST): CPU = 0.65e9, FPU = 0.24e9, ASM = 8.0e9, NEON = 6.0e9 ops/s; RAM-copy ST = 27 GB/s. • MT scaling addendum: MT sub-tests are normalized against an expected scaling model ref_MT(T) = base_per_thread × T^α. Exponents: α_CPU = 0.85, α_VEC (ASM/NEON) = 0.90. ≈1.0× means “as expected”; >1.0× means “better-than-expected scaling”. • Latency refs: L1 = 1.2 ns, DRAM = 100 ns. • Aggregate: weighted geometric mean with wST = 0.35, wMT = 0.30, wBW = 0.20, wLAT = 0.15; final score = round(1000 × Aggregate). TIPS FOR CONSISTENT RESULTS • Let the device cool and avoid charging during a run. • Close heavy background apps. • Watch the badge: “Throttling (~NN%)” usually implies performance loss. PRIVACY & PERMISSIONS • Data collection: none. • Network: not required. • Permissions: none beyond basics needed for operation. WHY KITBENCH? • Objective, repeatable numbers — not “gamified” scores. • Clear methodology you can verify. • Useful for enthusiasts, developers and anyone curious about real-world device performance. FAQ Q: Why isn’t MT = ST × cores? A: Real systems scale sub-linearly (memory/cache limits, scheduler overhead, big.LITTLE, thermal throttling, sync). Q: What is threads^α and why α = 0.85 / 0.90? A: It’s expected scaling: CPU/FPU α=0.85, ASM/NEON α=0.90. ≈1.0× means “as expected”; >1.0× means “better-than-expected scaling”. Q: Why reference anchors at all? A: Sub-tests have different units (ops/s, GB/s, ns). Anchors map them to dimensionless multipliers so domains can be aggregated fairly. Q: Do anchors favor a particular chipset? A: No. They set the scale. Devices exceeding expectations get >1.0× and score higher. Q: Why geometric means and domain weights? A: To reflect multiplicative effects and avoid domination by one outlier; weights (ST 0.35, MT 0.30, BW 0.20, LAT 0.15) define balance. Q: Why keep a Java test if ASM/NEON exist? A: To reflect real JVM/ART behavior (bounds checks, JIT/GC, branches, interpreter↔JIT). Q: Why do results vary between runs? A: Background activity, DVFS, temperature, affinity, OS power policies. Keep conditions consistent. COMPATIBILITY Android 8.0+ (API 26+); ASM runs in the bitness of the current ABI (armeabi-v7a = 32-bit, arm64-v8a = 64-bit); NEON required on ARMv7-A (present by default on ARM64).