System / Development
AmiBenchmark
0.50.25a
Parallel CPU benchmark based on the calculation of amicable numbers. Used to reproducibly compare computers, save results and work with benchmark workloads; conceptually predates the DCBench project.
What the project solves
Parallel CPU benchmark based on the calculation of amicable numbers. Used to reproducibly compare computers, save results and work with benchmark workloads; conceptually predates the DCBench project.
Typical use
- Comparison of CPU and multifibre performance of different computers
- Repeated benchmark runs with history of results
- Export / import results for further analysis
- Development and verification of other benchmark workloads
How the application works and what it is for
Executive Summaries
AmiBenchmark is a parallel CPU benchmark designed to go to use as performance diary as a team leader tool. The key value is not only the score itself, but the combination of score + methodology + conditions of measurement.
- Reproducibility: profile, conditions, 3-run median, same parameters.
- History: centralised record to SQLite with extensive metadata.
- Sharing: export of the pipeline (XLSX / TXT / JSON) and deduce import.
- Expansibility: workload API contract without falling the entire application.
Standard workflow (operator)
- Warm- up / dry run: short test of functionality of graphical interface, DB and exports.
- Test runs: at least 3 runes with the same preset.
- Median: evaluation through median, not single run.
- Record: DB entry with profile and conditions.
- Export: XLSX / TXT / JSON + optional charts to share jacket.
Export / Import of the pipeline (XLSX / TXT / JSON)
- XLSX: primary team format (filtering, graphs, review).
- TXT: fast text report.
- JSON: automation and scripting.
- Import: validation + deduce before entry into DB.
Troubleshooting (ops playbook)
| Symptom | Cause / Solution |
|---|---|
| Score's fluctuating significantly. | Power plan, throwing, background load, different preset. |
| DB locked | More instances over one DB; use one active instance. |
| Export XLSX Failed | The file is open, rights / path, or unicode path issue. |
| Workload drops app | The module must address exceptions and return error status. |
Recipes (operating scenarios)
RECEPT 01 - Publish the leaderboard for the team
- Select preset (Standard / Stability / Efficiency).
- Make 3 runs (or 1 long run stability).
- Save into DB (RECORD) and export XLSX.
- Create share ZIP: XLSX + TXT + config snapshot + graphs.
- Apply the deduce rules and the naming convention.
RECEPT 02 - Undervolt A / B test (stability profile)
- Run a baseball stability run without UV.
- Run the UV variant with the same preset.
- Compare median score, drift and thermal behavior.
- Write the terms (BIOS / power / cooling) in the notes.
RECEPT 03 - Nighttime batch benchmark (batch mode)
- Plan batch mode run with stable preset.
- Export results to the staging folder.
- Valid the dedupe and then import it into production DB.
RECEPT 04 - Follow Performance drift after BIOS update
- Before update create the reference 3-run median.
- Repeat the same preset and conditions after update.
- Compare the difference score / released / through a power profile.
RECEPT 05 - Compare Power Plans
- The same preset is started in Balanced / High Performance modes.
- Compare stability and absolute performance.
- Use the final plan for standardized team runs.
RECEPT 06 - Workload validation module
- Verify and mandatory encypoints.
- Run test and record mode, check stop / progress callbacks.
- Check that the module errors do not end the host application.
FAQ (extended operational question database)
Methodology and fairness
- How often do you repeat the benchmark? For a minimum of 3 runs, for stability, at least 1 longer run.
- Why use the median? The median eliminates one-off fluctuations caused by background load.
- Can I compare batteries vs. AC? Yes, but not in the same leaderboard.
- How to determine the reference preset? The team should publish fixed START / RANGE / CORES.
- Is the score compatible with the versions? Usually, yes, but when you change the algorithm, you need a note in the report.
- Should I state the ambient temperature? For longer runes, yes, it helps to interpret the drift significantly.
- How many cores to choose? By target: max power vs efficiency vs scaling.
- What is a minimum valid data set? Timestamp, preset, score, elapsed, CPU, OS.
- When is the run void? In runtime error, inconsistent parameters or strong external intervention.
- Can I mix different BIOS versions? Yes, but always separate them in the results.
Technical issues
- What do you do with DB lock? Close parallel instances, check access rights, repeat surgery.
- Why does XLSX export not work? Typically open target file or invalid path.
- How to verify the dedupe import? Import of the same data should not increase the number of unique lines.
- Can we do without music? Yes, music is optional and must not block the benchmark.
- Where is the configuration stored? To .
- How to reset the AI layout? Remove or modify the respective config keys.
- Where are the results stored? To SQLite DB ().
- Is it possible to use external workload? Yes, while complying with the API contract.
- What if the workload fires the exception? It's to be captured by the module and returned as error status.
- How often do you call a progress callback? Reasonably, typically up to 5 × / s
Performance analysis
- How do I know a thermal trottle? The drop of throughput in the final stage of the run.
- Will an undervolt help? Often, but only if it's stable.
- Can the RAM affect the score? Yes, especially latency / frequency during CPU-bound tasks.
- You want me to log the power draw? Yes, if you're doing an efficiency profile.
- How to assess stability score? Watch the variance between repetitions and drift trends.
- When to raise RANGE? When the quick test is too short to reveal the trotling.
- Is it good to turn off HT / SMT? Only under A / B test with the same methodology.
- What about the outlier run? Do not throw away without a reason; first diagnose.
- How to compare different OS? Specify separately and not use the common baseline without note.
- Why is score high, but elapsed too? Watch even through put; score itself is not enough.
Data governance
- How to prevent duplication? Use deduce key and timestamp bucket.
- How to mark test data? Add tag / preset and do not publish in the official list.
- Can I modify the historical data? Just auditably and with a note of reason.
- How to protect the integrity of DB? Regular backups and single- writer mode.
- How to synchronize the team? Central template + clear import rules.
- What about the data field conflict? Normalize mapping and reimport.
- How to solve unknown values? Use null / empty consistently, not ad- hoc text.
- Should I store the system metadata? Yes, they're increasing the analytical value of the data considerably.
- Is JSON export suitable? Yes, for an automation pipeline.
- How to audit import? Logo of the number of new / duplicate / rejected rows.
Extension and maintenance
- How to add a new workload? Create a module with mandatory entries.
- Does workload have to return the standard structure? Yes, because of the compatibility of graphical interface / DB / export.
- Can workload run without graphical interface? Yes, via batch mode, if the module supports it.
- How to deal with breaking change workload? Increase the module version and maintain back mapping.
- How to test workload update? QA matrix + regression dataset.
- Where to keep the documentation of the workload? README module + this enterprise page.
- How to keep localization consistent? Add new keys to both languages and fallback.
- When to clean old exports? According to the team's retention policy.
- How to validate a release candidate? Acceptance criteria in section QA protocols.
- What do you do when you're insecure about results? Repeat the tests under controlled conditions and attach notes.
