Performance results of different scheduling algorithms used in the simulation of a modern game engine
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
<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>
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,002 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,001 | 0,001 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,004 | 0,002 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,001 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle