ni.com checkout is currently experiencing issues.
Support teams are actively working on the resolution.
Discussions au sujet de NI LabVIEW
VI Analyzer (structure in place)
Résolu !
VI Analyzer ... structure "in place" ... peut-être une amélioration possible du diagnostic (?)
si VI Analyzer détecte les fonctions "replace array subset" et "index array" cablées "ensemble" ... alors il conseille d'utiliser la "structure in place".
Mais ...
il ne vérifie pas si les index sont identiques.
Je pense que cette vérification serait possible ... il faut un "fil simple / direct" entre les index des deux fonctions (sans aucune fonction intercalée)
Dans le cas contraire, le "in place" n'est pas applicable.
ici, il me conseille d'utiliser la strucure "in place" ... ce qui est impossible car les index sont différents.
(Sous condition, je fais "remonter" une ligne dans un tableau 2D. La ligne x prend la valeur de la ligne x-1)
Ne pas conseiller d'utiliser cette structure dans ce cas ... serait "un plus" pour cet outil d'analyse.
voilou, "petite idée" possible pour améliorer le diagnostic de VI Analyzer.
Ceci dit, VI Analyzer est un outil efficace, performant et bien pratique.
Bonjour,
Il est vrai que la structure In Place ne permet pas d'indexer et de remplacer a un autre index.
Ceci dit, le VI Analizer à aussi raison. Tel que le code est programmé dans votre VI, le tableau entrant est copié avant la fonction d'index. Je considére une bonne chose que l'analiser avertisse le programmeur de ce danger et de sa signification en terme d'utilisation mémoire dans le cas ou le tableau serait "gros".
La structure in Place permet de garantir de toujours utiliser la même copie du tableau (au détriment du temps d'execution, souvent plus lent).
Une solution pour réaliser votre algo in place serait un construction á deux structures
Cordialement
Bonjour Naity,
merci pour pour votre intervention.
et merci pour cette "éventuelle solution".
Dans le cas d'un Tableau de "grande dimension" ... votre solution est en effet intéressante.
une question secondaire m'interpelle
La structure "in place" évite de faire une copie des données concernées (faire une copie prend du temps)
et pourtant cette structure "in place" est "plus lente" ... comment cela se fait-il ???
merci.
ouadji wrote:La structure "in place" évite de faire une copie des données concernées (faire une copie prend du temps)
et pourtant cette structure "in place" est "plus lente" ... comment cela se fait-il ???
Bonjour (ou bonsoir),
La structure in place peut etre plus lente pour deux raisons.
La premiere a plus a faire avec la theorie de base du flux de donnees. "Un noeud ne peut etre execute que si toutes les valeurs presentes en entrees dont disponible. Une valeur ne peut etre retournee que si l'integrite du code present dans un noeud est execute" (ou similaire en francais). La structure in place est un noeud et se comporte comme tel. Selon la quantote de code present en son sein, la performance globale peut se trouver impactee.
La seconde est la raison principale: La structure in place est "bloquante". Pour des raisons evidentes de violation memoire, on ne p[eut pas permettre a deux thread paralleles d'acceder en meme temps au meme bloc memoire. Cela a peu d'impact pour un tableau, ou chaque nouveau "fil" represente un nouveau tableau. Mais a partir du moment ou la structure "en place" utilise des references (DVR), deux references ne peuvent etres ouvertes en parallele. La structure bloc donc le flux de donnees aussi longtemps qu'une instance parallele de la structure acced au meme bloc de donnees. Cela signifie aussi que la structure a un sorte de "semaphore" codee en fond. Comme tout algorithme, la semaphore necessite de la puissance de calcul pour etre executee.
Pour ces raisons il est communement admis que la strcuture In Place represente un echange entre l'utilisation memoire (moins de copies = plus de palce) et le temps d'execution (tructure bloquante, semaphore, moeud...etc). Ces considerations restent d'un impact pour une application "desktop" et prennent leur sens pour un systeme a temps reel.
J'espere que ceci repond a votre question 😉
Cordialement
De rien 😉
Par ailleurs, désolé pour les typos qui piquent un peu trop les yeux dans le post précédent. Ca m'apprendra à poster à des heures non réglementaires 😉
Bonne journée et "bon code"
ah oui ... je n'avais pas remarqué ... mais en effet ...
02.30 AM 
à ces heures là (dont je suis également et régulièrement adepte)
il ne reste plus que les passionnés et les "accros".
donc, vous êtes totalement excusé 
Bonne journée également.
PS
"je n'avais pas remarqué ... mais en effet ..."
Je parlais de "l'heure" ... pas des typos ... très peu nombreux en réalité.
Un dernier point qui peut être "interressant":
La copie d'un bloc de donnée en mémoire ne demande que trés peu de temps d'execution. Le processeur n'a pas besoin de reproceder les valeurs du tableau et peut se contenter d'envoyer une commande de copie à la RAM. Les rams standards des PC actuels (DDR3) ont selon leur architecture interne entre 6GB et 17GB/s de vitesse d'écriture max. Un tableau de 200MB peut être copié en une dizaine de millisecondes (plus un overhead ridicule de l'orde de quelques dizaines de nanosecondes pour traiter l'instruction). Pour une appli windows, sachant en plus que la la ram disponible par application n'est que de quelques GB, le temps d'execution n'a pas de gros impact sur le programme (les problèmes mémoires interviennent souvent plus vite que ceux de timing).
L'article wiki sur la ram est plutot bien foutu et "interressant" à lire (c'est clairement pas du Chateaubrillant mais pour peu que ce sujet interesse, ca regorge d'informations): SDRAM (wiki)
