Performance results of different scheduling algorithms used in the simulation of a modern game engine
Bibliographic record
Abstract
<strong>Performance results of different scheduling algorithms used in the simulation of a modern game engine</strong> These results are a companion to the paper entitled "<em>Exploring scheduling algorithms for parallel task graphs: a modern game engine case study</em>" by M. Regragui et al. <strong>General information</strong> This dataset contains raw outputs and scripts to visualize and analyze the scheduling results from our game engine simulator.<br> The result analysis can be directly reproduced using the script run_analysis.sh. A series of Jupyter Notebook files are also available to help visualize the results. <strong>File information</strong> - All Scenario*.ipynb files contain python scripts to visualize and analyze the simulation results.<br> - The Scenario*.py files contain python scripts that can be run directly with Jupyter Notebook.<br> - The requirements.txt file contains the names and versions of python packages necessary to reproduce the analysis.<br> - The run_analysis.sh file contains a bash script to install the required python packages and run the Scenario*.py scripts. The results are organized in five folders: 1. Result_1 contains the results for Scenario 1 generated using file input_scenario_1.txt.<br> 2. Result_2 contains the results for Scenario 2 generated using file input_scenario_2.txt.<br> 3. Result_3 contains the results for Scenario 3 generated using file input_scenario_3.txt.<br> 4. Result_CP_1 contains the results for the critical path of Scenarios 1 and 2 generated using file input_CP_scenario_1.txt.<br> 5. Result_CP_3 contains the results for the critical path of Scenario 3 generated using file input_CP_scenario_3.txt. Each result file (e.g., HLF_NonSorted_Random_1_200_10.txt) contains 200 lines representing information of the 200 frames that were simulated. Each line contains four values: the frame number, the duration of the frame (in microseconds), a critical path estimation for the previous frame (in microseconds), and the load parameter (value between 0 and 1). The outputs of this analysis include some PDF files representing the figures in the paper (in order) and some CSV files representing the values shown in tables. The standard output shows the p-values computed in parts of the statistical analysis. <strong>Software and hardware information</strong> The simulation results were generated on an Intel Core i7-1185G7 processor, with 32 GB of LPDDR4 RAM (3200 MHz). The machine ran on Ubuntu 20.04.3 LTS (5.14.0-1034-oem), and g++ 9.4.0 was used for the simulator's compilation (-O3 flag). The results were analyzed using Python 3.8.10, pip 20.0.2 and jupyter-notebook 6.0.3. The following packages and their respective versions were used: - pandas 1.3.2<br> - numpy 1.21.2<br> - matplotlib 3.4.3<br> - seaborn 0.11.2<br> - scipy 1.7.1<br> - pytz 2019.3<br> - python-dateutil 2.7.3<br> - kiwisolver 1.3.2 <br> - pyparsing 2.4.7 <br> - cycler 0.10.0 <br> - Pillow 7.0.0<br> - six 1.14.0 <strong>Simulation information</strong> Simulation results were generated from 4 to 20 resources. Each configuration was run with 50 different RNG seeds (1 up to 50). Each simulation is composed of 200 frames. The load parameter (lag) starts at zero and increases by 0.01 with each frame up to a value equal to 100% in frame 101. After that, the load parameter starts to decrease in the same rhythm down to 0.01 in frame 200. <strong>Algorithms abbreviation in presentation order</strong> FIFO serves as the baseline for comparisons. 1. FIFO: First In First Out.<br> 2. LPT: Longest Processing Time First.<br> 3. SPT: Shortest Processing Time First.<br> 4. SLPT: LPT at a subtask level.<br> 5. SSPT: SPT at a subtask level.<br> 6. HRRN: Highest Response Ratio Next. <br> 7. WT: Longest Waiting Time First.<br> 8. HLF: Hu's Level First with unitary processing time of each task.<br> 9. HLFET: HLF with estimated times.<br> 10. CG: Coffman-Graham's Algorithm.<br> 11. DCP: Dynamic Critical Path Priority. <strong>Metrics</strong> * SF: slowest frame (maximum frame execution time)<br> * DF: number of delayed frames (with 16.667 ms as the due date)<br> * CS: cumulative slowdown (with 16.667 ms as the due date)<br>
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.007 |
| Meta-epidemiology (narrow) | 0.002 | 0.000 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.001 | 0.001 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.009 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".