For_Loop (loop count + indexed tunel)

[ouadji]

Le "moralisateur intégré" (  ) de LV semble ne pas aimer une boucle For dans laquelle il y a :

- une valeur sur le "loop count"  ET   un tunnel indexé en entrée.

Pourtant il existe des cas où cela est bien utile.

Du point de vue "vitesse d'exécution", il est très intéressant de travailler sur des tableaux dont la taille est fixe et connue à l'avance par LV.

Par exemple, via un "initialize array" ou une "constante tableau". Ensuite on "agit" sur ce  Tableau  via des "replace array subset".

Résultat : Le code s'exécute sur un tableau de taille connue et  fixe.

Pourquoi ?

toute modification de la taille d'un Tableau coûte cher en temps.

par exemple ... 

via un "reshape_array" ou de façon plus indirecte (un rien plus caché) via un "delete from array"

à chaque fois que l'on "touche" (de façon directe ou indirecte) à la taille d'un tableau ... c'est payé cash en temps d'exécution.

Mais ...

même si on travaille sur un tableau de taille fixe, il est parfois nécessaire de ne traiter qu'une partie de ce Tableau.

Dans ce cas ...

une boucle For + un loop_count + un tunel indexé ... est bien utile.

Car ...

se passer du tunnel indexé d'entrée en utilisant la fonction "index array" dans la boucle ... est plus lent. (le tunnel indexé d'entrée est plus rapide)

ma question :

Bien que LV ne semble pas aimer un "loop_count" + "un tunnel indexé d'entrée" ( pourquoi ?)

existe-t-il une "réelle" contre-indication, désavantage, ou problème possible .... avec ce type de code.

Je rappelle que ... après des centaines de tests différents ... ce type d'approche me donne au final le code le plus rapide.

Réellement .. celui qui recherche un maximum de vitesse ... ne pas toucher à la taille des tableaux est un "gros plus".

merci à tous.

[JB · Accepted solution]

Si LV "n'aime pas" cette manière de faire, il ne l'interdit pas et je ne pense pas qu'il y ait la moindre contre-indication à s'en servir.

L'avertissement me semble justifié car il y a fort à craindre que des programmeurs moins expérimentés ignorent comment LV va se comporter dans ce cas. Mais il y fort à craindre aussi que ces même développeurs ne s'intéressent pas à l'avis du "moralisateur" au sujet de leur code.

PS : Que dit le "moralisateur" avec deux tableaux indexés en entrée de la boucle ?

[ouadji]

Merci JB pour cette réponse.

Que dit le "moralisateur" avec deux tableaux indexés en entrée de la boucle ?

rien !

(en effet ... pourtant " l'effet de bord" est identique ... bonne remarque)

[Eric.M]

Avec les deux méthodes (voire 3 si on ajoute un terminal d'arrêt), la LLVM ne peut pas optimiser le code pour les allocations mémoire (il ne sait quoi choisir) lors de la compilation.

A+

--Eric

[ouadji]

merci Eric pour ton intervention.

LLVM ?  .... LVM : je pense Labview manager ... mais le 1er L ?

[ouadji]

et non ... j'étais "à côté" !  

LLVM : Low-Level Virtual Machine.  ( ici )

[Eric.M]

Tu as failli me décevoir ! 🙂

[ouadji]

et oui ...

j'aurais du "voir" que cela ne pouvait pas être " truc-LabView-Manager " ...

puisque tu avais écrit  ...  la  LLVM ...

aarrgg ... pas attentif à 100% sur ce coup là ... j'aurais pu mieux faire !  

(  )