[REALISATION] Optimiser BOINC en modifiant les fichiers config

FAQ Technique > Tutoriels

<< < (2/3) > >>

LOCTET SetiOne:
Pour les discussions propositions d'insertion de .xml = http://forum.boinc-af.org/index.php/topic,5056.25.html#lastPost

GuL:
:hello: L'équipe a le bonjour de LOCTET SetiOne qui a débloqué le fil après que je l'ai contacté par MP. Il est "retiré des affaires".

Suite à un échange avec JeromeC, je reposte ici un tutoriel où il sera plus approprié.

--- Citation de: JeromeC le 10 November 2018 à 10:01 ---"libérer un thread par GPU dans les préférences locales" tu veux dire mettre x% d'utilisation CPU c'est ça ?

Et je suis désolé mais je comprends pas bien ton dernier message Gul, tu pourrais pas expliquer plus longtemps et surtout plus fort ? :siflotte:

--- Fin de citation ---

Décidément, c'est un sujet qui est difficile à comprendre, vu que nous en avons déjà parlé à plusieurs reprises. Mais je ne te jette pas la pierre, c'est sûrement moi qui explique mal. cocoricooo

Introducion
On va partir sur l'hypothèse d'un CPU avec 8 threads plus un GPU. Pour que le GPU ait suffisamment de travail, il faut qu'un thread CPU lui soit réservé. Même si le GPU n'utilise le CPU que par pic, il faut qu'il soit accessible dès que le GPU en a besoin pour éviter les creux d'utilisation. On va étudier trois configurations (default, app_config seul, app_config + préférences locales) et trois modes possibles (normal, haute priorité, machine virtuelle multi-thread).

A) Première configuration: default. On n'a fait aucune modification dans les fichiers de configuration et 100 % du CPU est dédié à Boinc dans les préférences locales.
1) Mode normal
Le GPU réclame 0.89 CPU (c'est un exemple), ce qui est inférieure à 1. Boinc ne connaissant que les valeurs entières de threads, il va lancer 8 tâches CPU plus une tâche GPU. Le GPU n'aura que les miettes du temps CPU et des trous de calcul seront présents.
2) Mode haute priorité
Une tâche passe en haute priorité et passe devant toutes les autres. Une tâche CPU s'arrête pour lui laisser sa place (comme quand on se lève dans le métro face à une personne âgée ;) ). La tâche GPU continue à tourner avec moins de miettes de temps CPU que dans le cas A1.
3) Mode machine virtuelle multi-thread
La tâche demande le nombre maximum de threads disponibles, soit 8. Ce mode est équivalent au mode haute priorité pour tous les threads à la fois. Le GPU n'a presque plus de temps CPU et se tourne les puces.

B) Deuxième configuration: fichier app_config. Les préférences locales conservent 100 % du CPU dédié à Boinc. Un fichier app_config.xml a été ajouté dans le dossier de tous les projets GPU, avec pour chaque application concernée une section comportant, entre autres:

--- Citer --- <gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>1</cpu_usage>
</gpu_versions>
--- Fin de citation ---
1) Mode normal
Le GPU réclame 1 CPU. Boinc va lancer 7 tâches CPU et réserver un thread CPU pour la tâche GPU. Le GPU sera suffisamment alimenté et n'aura pas de trous de calculs.
2) Mode haute priorité
Une tâche passe en haute priorité devant toutes les autres, y compris la tâche GPU. Cette dernière peut potentiellement repasser dans le cas A2.
3) Mode machine virtuelle multi-thread
La tâche demande le nombre maximum de threads disponibles, soit 8. C'est identique au cas A3 et le GPU se tourne les puces.

C) Troisième configuration: fichier app_config et préférences locales. Les préférences locales sont modifiées pour ne dédier que 87.5 % du CPU à Boinc, soit n-1 threads (7/8*100=87.5). Un fichier app_config.xml a été ajouté dans le dossier de tous les projets GPU, avec pour chaque application concernée une section comportant, entre autres:

--- Citer --- <gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.05</cpu_usage>
</gpu_versions>
--- Fin de citation ---
1) Mode normal
Le GPU réclame 0.05 CPU. Il n'aura pas de thread supplémentaire attribué par Boinc, mais ce n'est pas grave puisque un thread est libre dans les préférences. Boinc va lancer 7 tâches CPU et une tâches GPU, qui bénéficiera des 12.5 % restant. Le GPU sera suffisamment alimenté et n'aura pas de trous de calculs.
2) Mode haute priorité
Une tâche passe en haute priorité devant toute les autres, mais cela ne change rien pour le GPU qui n'a pas de temps CPU attribué par Boinc.
3) Mode machine virtuelle multi-thread
La tâche demande le nombre maximum de threads disponibles, soit seulement 7. Cela ne change rien non plus pour le GPU qui bénéficie toujours des 12.5 % restant du CPU. Il sera peut-être juste un peu ralenti à cause de la mémoire cache du CPU.

Conclusion
Comme on l'a vu ci-dessus, le GPU est impacté en permanence dans la configuration A. Dans la configuration B, des problèmes apparaissent dès qu'une tâche demande la priorité ou avec une VM multi-thread. Il n'y a que dans la configuration C que le GPU sera le moins impacté par les autres tâches. C'est celle que je préconise. En complément, il est possible de faire tourner deux tâches simultanées sur le GPU avec l'option <gpu_usage>0.5</gpu_usage> (1/2=0.5)

GuL:
En complément, voici un fichier app_config.xml pour primegrid, avec l'aide de DocPhilou :jap:, qui reprend un grand nombre de sous-projets, et qui configure à la fois les tâches GPU deux par deux et les tâches CPU multithreads, pour une machine avec 7 threads CPU et un thread réservé pour le GPU, dans les préférences locales, comme dans le cas C ci-dessus

--- Code: ---<app_config>

<app>
<name>pps_sr2sieve</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.05</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer15</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.05</cpu_usage>
</gpu_versions>
</app>


<app_version>
<app_name>llr321</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrCUL</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrESP</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrGCW</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrMEGA</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrPPS</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrPPSE</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrPSP</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrSOB</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrSR5</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrTPS</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrTRP</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
<app_version>
<app_name>llrWOO</app_name>
<cmdline>-t 7</cmdline>
<avg_ncpus>7</avg_ncpus>
</app_version>
</app_config>
--- Fin du code ---

JeromeC:
Il serait peut-être utile de préciser que les précos de Gul concernent surtout les projets GPU en OpenCL ?

J'ai la sensations que les projets CUDA (NVidia) n'ont pas ce besoin de CPU pour tourner correctement, du fait qu'ils sont directement compilés pour chaque carte graphique alors que l'OpenCL est générique et requiert une couche logicielle supplémentaire pour tourner (si je dis pas de bêtise). C'est ce que j'ai constaté avec la GeForce GTX 1080 de mon Shadow.

Pour AMD/Radeon je sais pas vu que sur mon vieux iMac et son merveilleux Radeon HD 4850 seuls quelques projets tournent en OpenCL.

GuL:

--- Citation de: JeromeC le 31 December 2018 à 11:16 ---Il serait peut-être utile de préciser que les précos de Gul concernent surtout les projets GPU en OpenCL ?

J'ai la sensations que les projets CUDA (NVidia) n'ont pas ce besoin de CPU pour tourner correctement, du fait qu'ils sont directement compilés pour chaque carte graphique alors que l'OpenCL est générique et requiert une couche logicielle supplémentaire pour tourner (si je dis pas de bêtise). C'est ce que j'ai constaté avec la GeForce GTX 1080 de mon Shadow.

--- Fin de citation ---
Je ne suis pas persuadé par ce que tu avances, mais je ne suis pas non plus suffisamment calé en programmation pour affirmer le contraire. D'après ce que j'ai compris, OpenCL compile le code (kernel) au début de l'éxécution, ce qui prend une seconde environ, tandis qu'il est compilé préalablement pour CUDA. Mais à ma connaissance, il n'y a pas de couche logiciel supplémentaire sous OpenCL.

L'utilisation ou non du CPU dépend des options utilisées pour la compilation ET pour l’exécution. Par exemple, dans la documentation de Seti Lunatics OpenCL SoG pour Nvidia, on peut augmenter ou réduire la charge CPU, ce qui aura un impact sur le temps de calcul GPU.

--- Citer ---With NV drivers past 267.xx GPU usage can be low if CPU fully used with another loads. App performance can
be increased by using -cpu_lock switch in this case, and CPU time savings are possible with -use_sleep switch.
--- Fin de citation ---

Ce qui est sûr, c'est que si on travaille sur plusieurs projets GPU, certains consomment du CPU, et d'autre non. Personnellement, je préfère utiliser une configuration systématique et ne pas me poser trop de questions, d'autant plus que ça dépend de la machine.

Navigation

[0] Index des messages

[#] Page suivante

[*] Page précédente

Utiliser la version classique