KitBench
10+
Downloads
Everyone
info
About this app
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).
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).
Updated on
Safety starts with understanding how developers collect and share your data. Data privacy and security practices may vary based on your use, region, and age. The developer provided this information and may update it over time.
No data shared with third parties
Learn more about how developers declare sharing
No data collected
Learn more about how developers declare collection
Committed to follow the Play Families Policy
What’s new
Bugs fixed
App support
About the developer
Віталій Кіт
vitkit.dev@gmail.com
Ukraine
