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).