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

VitKit

Additional Information