le 11-20-2015 02:11 AM
Bonjour,
Je viens vous faire part de mon étonnement face aux performances de la boucle "For" avec configuration d'itération en parallèle.
Lors de la réalisation d'un programme très rapide sous LV2014, j'avais découvert cela, et après un test unitaire rapide, je m'étais dit que c'était magnifique pour améliorer les performances sur des ordinateurs multi-coeur.
La phase d'euphorie passée, et un retour de performance utilisateur désastreux sur les performances de mon programm, j'ai jeté un oeil à mon programme, et après un nouveau test un peu plus poussé, je me rend compte que des que l'on résonne dans des boucles FOR imbriqué, les performances des itérations parallèles ne sont plus là bien au contraire.
Je partage avec vous mon VI de test afin de voir si le problème est uniquement du à mon poste, à une mauvaise interprétation du principe de boucle FOR.... ou autre.
Forcément ma pièce jointe est sous LV2014.
Bonne journée à tous.
Résolu ! Accéder à la solution.
le 11-20-2015 02:18 AM
En règle générale, lorsque l'on fait des optimisations, il faut faire un benchmark pour évaluer l'impact des modifications. Les optimisations préconisées par NI comme les boucles parallèles doivent être évaluées au cas par cas, en effet, les comportements varient en fonction d'une multitude de paramètres. Seul la mesure des temsp d'exécution peut aider
le 11-20-2015 02:33 AM
Je suis entièrement d'accord avec toi pour des systèmes complexes. Par contre mon VI de test est tout de même très basique, et ne fais pas appel à des opérations complexes, enfin à mon sens.
Je viens d'avoir une idée, l'écart de performance est peut être dû à une allocation de mémoire sur évaluée, dans le cas des boucles à itération en parallèle.
Après, en effet, je fonctionne par benchmark pour optimiser mon code, à part cette fois là, où j'ai codé en rapide pour faire plaisir au client, et je suis passsé à côté de certains trucs.....
Cdt,
Michael
le 11-20-2015 02:47 AM
Ha le code rapide pour faire plaisir au client... C'est toujours lui qui pose problème...
Même des optimisations simples doivent être "benchmarkées" (on a pas la maitrise du compilateur, qui au passage gère ses allocations mémoires et copies de données à sa manière qui n'est pas toujours reproductible (les algos sont très complexes))
11-20-2015 03:36 AM - modifié 11-20-2015 03:38 AM
Ha le code rapide pour faire plaisir au client... C'est toujours lui qui pose problème...
Et oui ....
Mais sinon notre vie de programmeur serait tellement monotone XD...
Mon poste avait aussi pour objectif de sensibiliser les personnes passant par là à cet aspect.
Bonne journée à tous.
Michael