Ritik Compute Power (RCP) Standard

A benchmark proposal for delivered performance and system capability

Ritik Sharma · Version 1.0 proposal · 6 November 2026

Publication status · Technical preprint and proposed specification. This document includes formal analysis and synthetic verification cases. The executable Core suite, reference measurements, and cross-platform validation are pending.

Abstract

A computing system can excel at a small workload, fail to fit a larger one, and deliver different throughput after reaching thermal equilibrium. Peak operation rates and composite benchmark scores answer narrower questions than this combination of performance and feasibility. Ritik Compute Power (RCP) proposes a two-part result. A dimensionless Core score summarizes verified end-to-end performance on a versioned workload profile. A mandatory capability signature reports raw results, feasible workload sizes under declared constraints, sustained behavior, energy, and failure reasons. The proposed Balanced profile assigns fixed weights to twelve workload categories. This paper defines eligibility, normalization, aggregation, and reporting, proves the score's principal mathematical properties, and gives a protocol for evaluating the method on heterogeneous systems. Comparability is defined by a shared workload contract and a declared system boundary.

The RCP Core equation

Plain-text equation · RCP = 100 * exp(sum(w_i * ln(r_i)))

Here $r_i$ is the higher-is-better performance ratio for workload $i$ against a fixed reference, and $w_i$ is its published profile weight. The weights sum to one. For speed or throughput, divide the measured result by the reference. For latency or time to completion, divide the reference by the measured result. Section 5 derives the equation and defines its mathematical guarantees.

1. Problem and contribution

A useful machine comparison answers two questions. How fast can each system finish the same correct work? Which jobs can each system finish within the required limits? These questions can yield different purchasing or deployment decisions. For example, a model that fits entirely in accelerator memory on one machine may need offload on another. Both machines can still return similar results on a smaller benchmark input.

RCP defines a joint publication contract for a workload-weighted ranking and measured evidence about system capability. The contract covers the hardware and software that participate in the declared run. A result can describe a laptop, workstation, server, or cluster if the system can run the specified workload profile under its rules. It may also describe how far an incompatible system got and where it failed.

The benchmark index is dimensionless. The scope of a claim is the workload profile, the implementation rules, and the test conditions. Computational rates retain their native units and precision. Electrical power is reported in watts and energy in joules.

2. Related work

Geometric aggregation of normalized benchmark results has established precedent in Fleming and Wallace [1]. SPEC CPU 2026 uses reference ratios and geometric means for speed and throughput, with explicit run and validation rules [2]. SPECworkstation 4.0 is the closest methodological precedent. It uses weighted geometric means of reference-normalized subtests and omits composite scores for categories or workloads with unavailable constituent results [3]. RCP adopts these principles and proposes a required companion report that ties feasibility, sustained performance, and energy to declared workload constraints.

MLPerf gives practical precedents for inference scenarios and accuracy requirements [4] and for measuring training time to a quality target [5]. Roofline relates attainable computational throughput to arithmetic intensity and bandwidth, illustrating why a compute peak alone describes only one limit [6]. Kalibera and Jones describe how experimental design and replication affect the uncertainty of performance comparisons [7]. The contribution proposed here is the reporting and comparison contract across workload families.

3. Benchmark contract

A benchmark revision freezes the workload manifest. A profile freezes the selected workload IDs and their weights. Before a revision can issue measured Core results, its manifest must publish the following.

Two implementation tracks may be defined. The controlled track fixes the algorithm and numerical format and permits only listed platform substitutions. The tuned track permits additional optimizations listed in the manifest, with shared input and output validation and explicit disclosure of algorithm or precision changes. CPU fallback is allowed where the workload permits it and the result passes the same validator. If a workload specifically requires a device path, the fallback cannot satisfy that requirement. Each track has its own identity and reference vector.

The system under test includes every component whose work is necessary for a timed result within the declared boundary. For an end-to-end job, the manifest specifies whether input staging, model loading, compilation, transfers, network exchange, and output persistence are inside the timing interval. Declare external load generators and shared services. A machine using a remote accelerator is evaluated under a system boundary that identifies the remote resource.

4. Proposed Balanced profile

The table defines the initial workload portfolio and weights. The entries specify the intended measurement. A released manifest must still supply the concrete workloads, inputs, constraints, and reference observations in Section 3.

The three AI categories account for 28% of Balanced. These are proposed design weights. A release must publish their rationale and assess ranking sensitivity to plausible changes. Correlated workloads can emphasize the same bottleneck even when their test names differ. Alternative profiles may be issued with independent identifiers and cannot share a leaderboard with Balanced. Media, graphics, networking, high-precision science, and specialized or emerging architectures may be served by separately versioned modules.

5. Mathematical method

5.1. Workload normalization and score

Let $I$ be the set of mandatory workloads in the profile and $n=|I|$. For workload $i$, $m_i(M)$ is the valid run-level aggregate for machine $M$, and $b_i$ is the fixed reference value. Both are finite and strictly positive and use the same unit. Define the dimensionless, higher-is-better ratio by

Equivalently, let $d_i=+1$ for higher-is-better metrics and $d_i=-1$ for lower-is-better metrics. Then $r_i=(m_i/b_i)^{d_i}$. A common unit conversion on $m_i$ and $b_i$ leaves $r_i$ unchanged. Profile weights satisfy $w_i>0$ and $\sum_{i=1}^{n}w_i=1$. For a system eligible under Section 6, the Core score $S$ is

For numerical evaluation, compute each log ratio as $d_i[\ln m_i(M)-\ln b_i]$. The log form avoids intermediate products of large and small ratios. Use unrounded inputs and round only the displayed score. A score of 200 means a twofold weighted geometric aggregate relative to the reference.

5.2. Derivation and assumptions

Let $F(\mathbf r)=S/100$ on positive ratio vectors. Consider a continuous positive aggregator with two design properties.

1. Multiplicative consistency. A componentwise change $\mathbf u$ followed by $\mathbf v$ gives $F(\mathbf u\odot\mathbf v)=F(\mathbf u)F(\mathbf v)$. Here $\odot$ means componentwise multiplication.
2. Specified workload sensitivity. Doubling only workload $i$'s oriented ratio gives $F(\mathbf 1+\mathbf e_i)=2^{w_i}$, where $\mathbf e_i$ is the $i$-th coordinate vector.

Proposition 1. These properties uniquely give Equation (2). Define $g(\mathbf x)=\ln F(e^{\mathbf x})$, with exponentiation applied componentwise. Consistency gives $g(\mathbf x+\mathbf y)=g(\mathbf x)+g(\mathbf y)$. Additivity gives rational homogeneity, and continuity extends it to all real scalars. Thus $g(\mathbf x)=\sum_i a_i x_i$. The doubling condition gives $a_i\ln 2=w_i\ln 2$, so $a_i=w_i$. Substituting $\mathbf x=\ln\mathbf r$ proves the result. Conversely, Equation (2) satisfies both properties.

These assumptions specify how normalized speed changes combine. The argument leaves the weights and choice of workloads to the profile. Those are design decisions that require empirical evaluation.

5.3. Comparisons, dominance, and profile sensitivity

Proposition 2. A shared reference cancels in a comparison. For eligible machines A and B tested under the same rules, define $\Delta_{AB}=\ln(S_A/S_B)$. Equation (2) gives

Each term compares like units on the same workload. A change to the common reference vector rescales both displayed scores by the same factor and leaves $\Delta_{AB}$ unchanged. Published scores still retain their reference identifier.

Proposition 3. With positive weights, a machine that matches or outperforms another on every workload and strictly outperforms it on at least one has a higher Core score. Under these conditions, every oriented log ratio in Equation (3) is nonnegative and at least one is positive. Also, since $\sum_i w_i\ln r_i$ is a convex combination of log ratios, $\min_i r_i \le S/100 \le \max_i r_i$. Multiplying every $r_i$ by $k>0$ multiplies $S$ by $k$. Multiplying only $r_j$ by $k$ multiplies $S$ by $k^{w_j}$.

Ranking reversals. A ranks ahead of B exactly when $\Delta_{AB}>0$. If some workloads favor A and others favor B, changing weights can cross the tie condition $\Delta_{AB}=0$. In the two-group example in Section 9, A runs the AI group at half the reference speed and the remaining group at twice the reference speed. If the AI group has total weight $a$, then $S_A/100=2^{1-2a}$. The ranking reverses at $a=0.5$. Each comparison therefore needs its profile label and per-workload results.

5.4. Feasibility and energy

Let $x$ denote a workload configuration, including input size and any tested concurrency or model settings. For an example where quality $Q$ must reach a minimum and elapsed time $T$ and energy $E$ must stay below limits, define the tested feasible set

The manifest names the applicable constraints and specifies whether they are evaluated on a single run, across repeats, or on a statistic such as p95 latency. For an ordered size coordinate $s(x)$, report $s_{\max}^{\mathrm{verified}}=\max_{x\in\mathcal F_M}s(x)$ when $\mathcal F_M$ is nonempty and the other comparison conditions are held fixed. An empty feasible set means none of the tested cases met the contract. When several dimensions vary, report the verified combinations as specified in Section 7.

For measured power $P(t)$ over $[t_0,t_1]$, with $N_{\mathrm{valid}}>0$ correctly completed jobs in that interval, define

Energy is in joules, average power is in watts, and $E_{\mathrm{job}}$ is in joules per correct job. Report the method used to approximate the integral from sampled data. Power, energy, and size remain separate fields. If faster memory or another subsystem improves delivered work, its effect already enters Equation (2) through the workload metric.

5.5. Measurement uncertainty

Let $\mathbf z=(\ln r_1,\ldots,\ln r_n)^\mathsf T$ be the estimated log-ratio vector and let $\Sigma=\mathrm{Cov}(\mathbf z)$ describe its estimation uncertainty. The log score is linear in $\mathbf z$, so its variance is

The off-diagonal terms account for shared variation, such as a common run session. Treat the reference as fixed for uncertainty conditional on the published baseline. If estimating uncertainty relative to a physical reference system, include its measurement variation too. For a direct A/B comparison, compute uncertainty from the log speed differences in Equation (3), using the actual pairing or independence of the measurements. The common reference cancels in that comparison.

Where there are enough independent experimental units, estimate intervals by resampling at the level implied by the design, preserving shared session blocks or A/B pairs, and recomputing the complete workload summaries and score. Exponentiate log-scale interval endpoints to return to score or ratio units. With sparse data, publish the observed repeat values and variability and state when the data cannot support a useful interval. A point score ratio above one can coexist with an interval that includes one.

6. Eligibility and failure reporting

Every workload in a profile is mandatory for a full Core score. Record each workload as pass, incorrect_output, quality_target_not_met, service_target_not_met, capacity_exceeded, timeout, unsupported, harness_unavailable, invalid_measurement, or not_run. Include supporting observations and the test conditions. A timeout alone does not establish a capacity limit. A missing runner and a confirmed system limitation are distinct findings.

Issue a numeric Core score only when all profile workloads have valid scoring measurements and all comparison identifiers match the reference. Otherwise record Core score unavailable, report the number passed out of the total, and publish the available observations and failure reasons. Never substitute a zero, silently remove failed workloads, or recompute weights. A separate subset profile requires its own manifest, reference, and label.

7. Required capability signature

When an applicable field cannot be measured, report it as unavailable with a reason. A Core score can be valid when separate diagnostics are unavailable, provided all mandatory scoring observations are valid and the publication discloses the coverage gap. Cost, acoustics, physical size, and emissions may be reported in separate context fields.

Feasibility. For each designated capacity test, publish the attempted sizes and the conditions held fixed. For model serving, those conditions include model and quantization, context length, batch size or concurrency, the latency and quality requirements, and the offload policy. The maximum reported value is the largest verified size among the attempted cases. Report larger attempted failures and any gaps. For multidimensional sweeps, publish the tested combinations and their outcomes. Do not infer an untested limit from a pass and a failure unless the manifest justifies the assumption used to infer it.

8. Measurement protocol

1. Document the configuration. Record hardware, firmware, OS, runtime, compiler, drivers, power mode, cooling, measurement boundary, and relevant ambient conditions. Identify source revisions and hash inputs and artifacts. Publish enough information for another operator to reproduce the run.
2. Control the run sequence. Define cold and warm states, cache policy, preconditioning, and background load. Use the same procedure on the reference and evaluated systems. For sustained performance, freeze the preconditioning interval, measurement window, and any stability criterion in the manifest.
3. Validate completed work. Apply the output or quality validator to the timed workload according to the published procedure. Record attempted runs, retries, and failures. Predeclare exclusion criteria and retain excluded observations with reasons.
4. Measure variation. Collect at least three valid independent repeats for each scoring workload and use the median of the run-level metric. The manifest may require more repeats, particularly for stochastic training and variable workloads. Publish repeat values and sample sizes. Where intervals are reported, state their method and resampling unit. Inferences about reproducibility across laboratories require independent runs at that level.
5. Measure energy on a matched interval. Integrate measured electrical power over the declared work interval and divide by the number of correct jobs completed. State whether the meter covers AC wall input, DC input, battery discharge, or a subsystem. Identify the instrument, sampling interval, and any separate idle correction. Report the total energy observed before any idle adjustment. For a cluster, identify every participating node and disclose whether the reported boundary includes networking equipment.

Compare scores only within the same benchmark revision, profile, implementation track, reference ID, and operating mode under compatible system-boundary rules. Version bridges use overlap runs on shared systems and tasks to quantify what changed. They do not establish that differently defined scores are interchangeable.

9. Synthetic verification

The following inputs are constructed to exercise the method. Each ratio already uses the higher-is-better orientation in Section 5.

For a separate energy check, a hypothetical 40-second run averaging 120 W uses 4,800 J. If it completes 24 correct jobs during that interval, Equation (5) gives 200 J per correct job.

A reference evaluator can compute the score by matching observations to manifest IDs, checking the comparison identifiers and eligibility, accumulating the weighted log ratios, and exponentiating once. Display rounding takes place after aggregation. Store raw measurements at the precision captured by the benchmark.

10. Validation plan and release criteria

A runnable RCP release requires a published manifest and runner, workload validators, reference observations and raw logs, and a score implementation that passes the verification cases above. Validation should then test three separate claims.

The Balanced profile also needs a sensitivity analysis across plausible weight sets and an audit for redundant workloads. Report ranking reversals and their causes. Future revisions should state the supported comparison domains and the workloads left to specialized modules. Claims about accuracy, predictive value, or superiority over another benchmark require hardware data and a documented evaluation.

References

1. Fleming, P. J., and Wallace, J. J. (1986). How Not to Lie with Statistics: The Correct Way to Summarize Benchmark Results. Communications of the ACM, 29(3), 218–221. DOI
2. Standard Performance Evaluation Corporation. SPEC CPU 2026 Run and Reporting Rules. Official specification
3. SPEC Graphics and Workstation Performance Group. (2024). SPECworkstation 4.0 User Guide. Official guide
4. Reddi, V. J., et al. (2020). MLPerf Inference Benchmark. 47th Annual International Symposium on Computer Architecture. Proceedings · Preprint
5. Mattson, P., et al. (2020). MLPerf Training Benchmark. Proceedings of Machine Learning and Systems, 2. Proceedings
6. Williams, S., Waterman, A., and Patterson, D. (2009). Roofline: An Insightful Visual Performance Model for Multicore Architectures. Communications of the ACM, 52(4), 65–76. DOI
7. Kalibera, T., and Jones, R. E. (2013). Rigorous Benchmarking in Reasonable Time. ACM SIGPLAN International Symposium on Memory Management. DOI

Suggested citation · Sharma, R. (2026). Ritik Compute Power (RCP) Standard: A Benchmark Proposal for Delivered Performance and System Capability. Version 1.0 proposal.