Gérez et mettez à jour manuellement le graphique de flux Intel TBB?

Question

J'ai réussi à prototyper une application en utilisant la géniale bibliothèque de graphes TBB d'Intel. Cela semble fonctionner plutôt bien, mais maintenant je dois refactoriser le code dans une version prête pour la production.

Auparavant, j'ai travaillé avec des frameworks plus grands et plus "surdéveloppés" pour ce domaine particulier (le travail est dans le traitement d'image et les applications précédentes ont utilisé ITK/VTK). Pour cette application, cependant, j'essaie de prendre une approche de niveau inférieur et plus ciblée.

Actuellement, je suis en train d'assembler tout mon graphique en main() ce qui n'est évidemment pas viable. Je voudrais autoriser le pipeline à fonctionner de manière itérative afin que je puisse saisir les données de sortie de chaque étape et les afficher à des fins de débogage/d'analyse. Mon idée jusqu'ici est de faire abstraction de chaque «étape» logique de l'application dans une classe qui accepte un &tbb::flow::graph comme argument constructeur et stocke en interne une référence au nœud graphique qu'elle contrôle. Je peux avoir la classe wrapper allouer tbb::flow::broadcast_node supplémentaire à la sortie et un noeud asynchrone après cela pour déclencher des événements.

Est-ce un concept de conception raisonnable? De manière générale, comment les autres ont-ils intégré les concepts de graphe de flux TBB dans la structure de leur application? Les exemples et la documentation sont assez rares pour cette partie particulière de la bibliothèque TBB.

Answer 1

Comme pour tout design, je ne pense pas qu'il y ait une bonne ou une mauvaise façon de le faire. Je ne connais pas votre code assez bien, mais casser le code par étapes logiques est probablement une bonne idée. En ce qui concerne les frameworks comme TBB, une décision de conception que vous devez prendre est de savoir si vous devez masquer tous les aspects du framework derrière une interface. L'avantage est que vous pouvez ultérieurement échanger l'implémentation avec une autre implémentation (par exemple, remplacer TBB par OpenMP). D'un autre côté, l'introduction d'une couche supplémentaire peut ne pas être nécessaire dans tous les cas. Surtout, s'il est peu probable que vous ayez remplacé TBB.

La conception que vous décrivez dans votre question concerne la structure de la pièce dépendante du cadre. Cela dépend beaucoup de l'algorithme concret que vous implémentez. Par exemple, si elle consiste à appliquer des transformations séparées sur une image, la création d'une classe par étape de transformation pourrait être une bonne approche.

En outre, il peut être judicieux de tout emballer dans une fonction ou une classe. Si l'opération que vous implémentez prend une image en entrée et produit une image en sortie, c'est quelque chose qui peut être caché derrière une interface qui cache les détails de l'implémentation (dans ce cas TBB).