BeeBench Methodology

1. The Measurement Principle

Engineering decisions require empirical data, not marketing benchmarks. BeeBench adheres to a strict principle: measure sustained execution under controlled, observable conditions. We reject single-number scores that conceal thermal throttling, memory exhaustion, or clock-frequency degradation.

2. Data Integrity Rules

• Unit Invariance: Metric units (e.g. milliseconds, mega-operations per second, degrees Celsius) are canonical and never silently coerced or combined across mismatched workload types.
• Honest Absence: Unknown environmental conditions remain explicitly marked as unknown; missing data is never represented as zero.
• Protocol Compatibility: Comparisons are valid only between identical protocol versions. Workloads run under different protocol configurations are explicitly labeled as exploratory.
• Sanitization & Privacy: Public reports exclude serial numbers, MAC addresses, device advertising IDs, and personal identifiers. Only hardware model, chipset, RAM tier, and OS build are retained.
• Revision Traceability: Corrections or withdrawals to published runs retain versioned audit histories.

3. Workload Categories

BeeBench implements several native compute kernels executed directly in native C++ via the Android NDK:

• Sustained Matrix Compute: Evaluates continuous floating-point throughput and thermal stability over multi-minute sessions.
• Memory Bandwidth & Pressure: Stresses mobile memory controllers with sequential and randomized block allocations.
• Thermal Telemetry: Samples device thermal zone temperatures at 1000ms intervals to track cooling efficiency.

4. Known Limitations

Mobile benchmarks are influenced by ambient room temperature, battery state-of-charge, and background OS scheduling. Published results represent specific observed physical device runs and do not guarantee identical performance on all consumer units.