groupe-dfo-bbo:projets:nomad:architecture:evaluation-queue

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision 		Révision précédente
groupe-dfo-bbo:projets:nomad:architecture:evaluation-queue [2021/06/29 21:44]
rochvivi 		groupe-dfo-bbo:projets:nomad:architecture:evaluation-queue [2021/07/09 20:58] (Version actuelle)
rochvivi
Ligne 1: Ligne 1:
-====== Evaluation Queue ======+===== EvaluatorControl and Evaluation Queue =====
  
 +Parallelism is central in the development of NOMAD 4. NOMAD 4 supports OpenMP to use many threads at the same time. Note that it is also possible to compile without OpenMP. It is also possible to limit the number of threads used (parameter ''​NB_THREADS_OPENMP''​). MPI is not currently supported in NOMAD 4 (it was used in NOMAD 3).
 +
 +==== Evaluation Queue ====
 The ''​EvaluatorControl''​ manages the evaluations. It has a queue of ''​EvalQueuePoints''​ which are points that need to be evaluated. The points are generated by ''​SearchMethods'',​ ''​PollMethods'',​ or other ''​Steps''​ derived from ''​IterationUtils''​. The ''​EvaluatorControl''​ also handles the Evaluator(s). The ''​EvaluatorControl''​ manages the evaluations. It has a queue of ''​EvalQueuePoints''​ which are points that need to be evaluated. The points are generated by ''​SearchMethods'',​ ''​PollMethods'',​ or other ''​Steps''​ derived from ''​IterationUtils''​. The ''​EvaluatorControl''​ also handles the Evaluator(s).
 +
 +The ''​EvalQueuePoints''​ know which ''​Evaluator''​ is needed to evaluated them. The evaluation queue contains all points that need to be evaluated, whether the evaluator is a model, a surrogate, or a blackbox (or other).
  
 The queue is implemented by a vector. The queue is implemented by a vector.
Ligne 7: Ligne 12:
 {{ :​groupe-dfo-bbo:​projets:​nomad:​architecture:​queue1.png?​400 |}} {{ :​groupe-dfo-bbo:​projets:​nomad:​architecture:​queue1.png?​400 |}}
  
 +
 +==== Sorting the Queue ====
 Points may be ordered before evaluation. This is useful for opportunistic evaluation, more so when there is little CPU available (few threads for OpenMP). Points may be ordered before evaluation. This is useful for opportunistic evaluation, more so when there is little CPU available (few threads for OpenMP).
  
Ligne 14: Ligne 21:
 {{ :​groupe-dfo-bbo:​projets:​nomad:​architecture:​queue2.png?​400 |}} {{ :​groupe-dfo-bbo:​projets:​nomad:​architecture:​queue2.png?​400 |}}
  
 +==== Evaluation of Points ====
 The way the ''​EvaluatorControl''​ is implemented,​ the points at the end of the vector are evaluated first - they have the greatest priority. The way the ''​EvaluatorControl''​ is implemented,​ the points at the end of the vector are evaluated first - they have the greatest priority.
  
Ligne 20: Ligne 28:
 {{ :​groupe-dfo-bbo:​projets:​nomad:​architecture:​queue3.png?​400 |}} {{ :​groupe-dfo-bbo:​projets:​nomad:​architecture:​queue3.png?​400 |}}
  
-//bla, bla, bla...// +When a point is evaluated, updates are done: 
- +  * If opportunism is used, a ''​FULL_SUCCESS''​ will stop evaluations. Evaluations that are already in progress will continue, but no new evaluation will be started. 
-(more to be added). +  * ''​Eval''​ of the point, i.e., evaluation information,​ is updated in the cache. 
- +  * The stats to be displayed are updated. 
-**Ignore remaining lines, this is brouillon:​**+  * Some members of ''​EvaluatorControl''​, like the counter for the number of evaluations,​ are updated.
  
-Quand le point est évalué, des valeurs sont mises à jour : +==== Main thread(s) and secondary threads ==== 
- - L’évaluation du point dans la cache; +OpenMP computes the number of available threads and uses them all, unless ''​NB_THREADS_OPENMP''​ is set, in which case this number of threads is used. There is one main thread, which is thread number 0. The other threads are secondary threads. The main threads is the only one that generates points and adds them to the evaluation queue; it is also used for evaluations. The secondary threads are used solely to run the ''​Evaluator''​ for evaluating points.
- - Les membres de l’EvaluatorControl, comme le  +
-   ​nombre d’évaluations +
- - Les stats pour l’affichage +
- - Et si l’opportunisme est utilisé, un succès arrête les +
-   ​évaluations. Les évaluations déjà commencées vont +
-   se terminer, mais aucune nouvelle évaluation ne sera +
-    débutée.+
  
 +When evaluations are done because all points in the queue are evaluated, or because of opportunism,​ only the main thread exits from the EvaluatorControl'​s ''​run''​ method. The secondary threads keep looping inside the ''​run''​ methods while waiting for new points to evaluate.
  
-Quand les évaluations sont terminées, à cause d’une +In the case of ''​PSD-Mads''​, there is more than one main thread. Each subproblem has its own main thread ​that generate points and manages algorithms. There can still be additional secondary ​threads ​for evaluation only. The main thread 0 is used for the pollster and for the management of the PSD-Mads algorithm. Note that any thread may run the evaluation for a point generated from any main thread: it is always the next thread that is available that will evaluated the next point in the queue.
-Condition d’arrêt, un seul thread ​(le main thread) sort  +
-De la fonction run de l’EvaluatorControl. Les autres ​threads +
-Continuent à rouler dans la fonction ​run +
-en attendant de nouveaux points +
-À évaluer.+
  
  
-Dans le cas de PSD-Mads, on a un main thread par +==== Blocks of points ==== 
-Sous-problème, plus d’autres ​threads ​secondaires +The ''​EvaluatorControl''​ always pops blocks of points from the evaluation queue, but usually these blocks have only one point. If ''​BB_MAX_BLOCK_SIZE''​ is more than 1, blocks of this size will be popped. The points inside the block may come from different main threads ​(if applicable),​ but they all need to be evaluated with the same ''​Evaluator''​. In this use case, the Evaluator needs to know how to evaluate a block of points. The opportunity condition, if applicable, is verified after all points in the block are evaluated.
-Qui ne sont utilisés que pour des évaluations. +
  • groupe-dfo-bbo/projets/nomad/architecture/evaluation-queue.1625003055.txt.gz
  • Dernière modification: 2021/06/29 21:44
  • par rochvivi