File Globali

[renaso]

Salve a tutti,
vorrei sapere una curiosità.
sto usando diverse globali nel mio progetto:
booleane, com seriali, array, reference a code ecc.
Come conviene usarle in termini di prestazioni??
Mi spiego: è meglio avere 1 solo file.vi con all'interno più globali oppure più file, magari separando i tipi di dato per ogni file, oppure non cambia assolutamente nulla in termini di compilazione e performance???

Grazie

[renaso]

Riesumo un post che avevo fatto tempo fa ma senza risposte perchè ora mi ritrovo a dover gestire diversi task in parallelo che hanno a che fare con diverse strumentazioni e ovviamente hanno altri obiettivi...
Ovviamente per una questione di pulizia mi conviene fare un vi globale per ogni task ma anche questa volta mi viene il dubbio!!!

A livello di processore, di sistema, di ram, e quindi a livello di velocità d'accesso alla risorsa globale conviene avere più file vi globali e di conseguenza ognuno di piccole dimensioni, con meno controlli all'interno o un solo file globale, per l'intero sw, magari un file anche di 500Kb, oppure se il file global.vi è di piccole dimensioni il sw ci mette meno tempo per rintracciare la risorsa che voglio all'interno del vi?

Lo so che la domanda può sembrare inutile, infatti è solo una curiosità... Programmo sempre usando più FGV possibili...

[giuseppe.l74]

scusa, mi sono imbattuto nel tuo post e la curiosita' e' sorta a me.. cosa sono le fgv?

[renaso]

FGV = Functional Global Variable
è una tecnica di programmazione che elimina i problemi che i file globali potrebbero causare, oltre che esssere molto utile e intuitivo a livello di leggibilità di codice.

C'è un post di pochi giorni fa dove aris ha postato un esempio, sul sito national trovi moltissimo

viewtopic.php?f=1&t=5770#wrap

[Ricky]

Ciao Renaso,

In termini di prestazioni direi che le variabili globali non sono il massimo, come le metti metti. Oltretutto non garantiscono il controllo d'accesso alla variabile. Sicuramente le FGV sono sicuramente un metodo migliore per garantire un controllo migliore all'accesso delle variabili ma perdono prestazione e funzionalità quando si usano in parallelo. Si ottengono risultati migliori invece utilizzando i DVR (Data Value Reference) e le SEQ (Single Element Queue) (che come prestazioni sono le più efficienti). Io normalmente mi uso delle SEQ in quanto possono essere richiamate per nome, creo delle librerie che permetto la gestione dell'accesso ai dati. Per chi vuole approfondire trovate maggiori informazioni sul sito della NI.

[aris]

Ciao ragazzi!
Mi sono un pochino chiamato in causa......


Riky, hai mai fatto un test sulle differenze di performance dei tre tipi di design pattern?

Intendo, a parte le differenze di "utilizzo" tra i 3 che possono essere implementati, a parte la sicuramente miglior gestione della memoria dei DVR e delle SEQ rispetto ai Moduli.....

A livello di tempo di esecuzione, mi sembra che le FGV siano le più efficienti.....

E' veramente una curiosità, io ho fatto una provettina al volo ed ho notato differenze significative.....


Aris

[Ricky]

Ciao ragazzi!

Riky, hai mai fatto un test sulle differenze di performance dei tre tipi di design pattern?

Aris

Si, ho fatto un test del genere. I risultati del mio test sono discordanti dal tuo. In termini di tempo di esecuzione a me non si sono verificate grandi differenze tra l'utilizzo di un metodo rispetto a l'altro. Ora però bisogna vedere come hai eseguito tu il test e come l'ho fatto io.

Ti allego il mio test così puoi capire come ho eseguito il tutto.

Sicuramente però le SEQ hanno il difetto di prendere più tempo in fase di progetto ma sicuramente sono meglio gestibili nell'applicazione, soprattutto se devi usarle in tasks paralleli. Hai mai provato a usare le FVG in parallelo? Io si e mi hanno sempre causato grossi problemi proprio perchè non garantiscono un controllo di accesso all'informazione.

[renaso]

Ricky, sto notando lo stesso malfunzionamento delle FGV richiamate in più task paralleli.
Ad esempio in un task acquisisco dalla scheda NI e butto in coda;
in un altro task scodo direttamente dentro alla FGV;
in altri task richiedo i dati alla FGV;

Non mi sembra un ottimo modo di utilizzare le fgv...

[aris]

Ottimo Riki,
ovviamente ho notato delle differenze se vado ad eseguire il codice N volte (esasperando il tutto......).

Sicuramente è un fattore trascurabile sulla "singola" chiamata, e perde perso rispetto alla miglior gestione della memoria.
Cosa intendi con "non garantiscono un controllo di accesso all'informazione"?

Renaso......non ho ben capito il tuo problema......
Noti lo stesso problema sulle SEQ che ha descritto Riky per le FGV?

Aris

[renaso]

no no..
dico solo che sto provando le FGV come da me descritto sopra e mi sembra che le performance non siano ottime, soprattutto se utilizzate in parallelo come detto...
ma non le ho confrontate con le SEQ (mai utilizzate in questo modo ma solo come code di dati)..
purtroppo non posso postare il codice ma quando avrò più info posterò la soluzione..

[Ricky]

Cosa intendi con "non garantiscono un controllo di accesso all'informazione"?

Renaso......non ho ben capito il tuo problema......

Aris

Se ben progettate (Vedi esempio) le SEQ garantiscono il controllo di accesso simultaneo, infatti dovendo eseguire il "Dequeue" prima di accede all'informazione (in scrittura ovviamente) vige la regola che chi prima accede alla risorsa blocca gli altri accessi, è una funzionalità intrinseca delle code. Questo comportamento non è garantito nelle FVG, quando accedi in scritture simultanee, nella funzione non è garantito che non si creino "raice condition" e non sai esattamente quando e chi ha scritto cosa! (spero di essere stato chiaro! Scusa se non lo sono stato, ma non è facile da descivere a parole.)

Renaso......non ho ben capito il tuo problema......

Aris

Non capisco nemmeno io... Cosa intendi esattamente?

[ale914]

Se ben progettate (Vedi esempio) le SEQ garantiscono il controllo di accesso simultaneo, infatti dovendo eseguire il "Dequeue" prima di accede all'informazione (in scrittura ovviamente) vige la regola che chi prima accede alla risorsa blocca gli altri accessi, è una funzionalità intrinseca delle code. Questo comportamento non è garantito nelle FVG, quando accedi in scritture simultanee, nella funzione non è garantito che non si creino "raice condition" e non sai esattamente quando e chi ha scritto cosa! (spero di essere stato chiaro! Scusa se non lo sono stato, ma non è facile da descivere a parole.)

In realtà non è così, le Functional Global essendo dei VI "normali" eseguono in modo esclusivo (una alla volta, è la regola dello scheduler di LabVIEW) quindi la race condition non possono accadere (come invece possono accadere con le variabili globali).

Il metodo delle SEQ l'avevo già visto in passato ma non l'ho mai usato, farò delle prove per vedere le performance.

In generale uso le FG non sollo per fare push e pull di dati ma per "lavorare" su questi dati (da cui il nome functional) scrivendo direttamente nel codice della FG le funzioni che mi servono su quei dati (filtra, ordina, elimina ecc) in questo modo le FG sono veramente molto utili.

In effetti in un'architettura dove ad esempio ha un produttore di dati che scrive su una FG e 1000 (ipotetici) VI client che leggono da quella FG i dati, l'uso delle FG sarebbe deleterio proprio per il fatto che LabVIEW ne mette in esecuzione una alla volta per cui i miei 1000 VI avrebbero parecchio da aspettare oltre al fatto che non si potrebbe sapere a priori quanto tempo e in ogni caso questo tempo non sarebbe costante da iterazione a iterazione

[aris]

Finalmente qualcuno "dalla mia parte"

Scherzi a parte, Ale ha riassunto perefettamente il concetto.
L'esempio che ha postato Riky, contempla delle differenze sostanziali tra le FGV e le SEQ.

Per fare in modo che le 2 tipologie siano uguali (variando solamente il tipo di store in memoria), la SEQ read deve SOLO decodare il dato, mentre la SEQ write lo deve SOLO accodare.

In quel modo si possono implementare una sorta di FGV ma che "storano" il dato in una coda (non in uno shift register)!

Un'altro "difetto" dell'esempio di Riky è proprio quello di non avere controllo sulla sequenzialità delle operazioni sul dato.
Sempre riferendomi all'esempio postato, in caso di parallellismo, non ho la certezza che chi legge abbia sempre accesso (in maniera sequenziale) ad un dato "elaborato" da chi scrive.


Aris

[Ricky]

[..]
Per fare in modo che le 2 tipologie siano uguali (variando solamente il tipo di store in memoria), la SEQ read deve SOLO decodare il dato, mentre la SEQ write lo deve SOLO accodare.
Aris

Ma si chiamamno proprio Single Element Queue (SEQ) proprio perchè hanno la particolarità di contenere sempre un elemento. Facendo solo l'encode in scrittura e il solo decode, non avresti un storage del dato. Avresti il dato immediatamente dopo ad una scrittura...

[..]
Un'altro "difetto" dell'esempio di Riky è proprio quello di non avere controllo sulla sequenzialità delle operazioni sul dato.
Sempre riferendomi all'esempio postato, in caso di parallellismo, non ho la certezza che chi legge abbia sempre accesso (in maniera sequenziale) ad un dato "elaborato" da chi scrive.
Aris

anche questa è una particolarità delle SEQ, infatti danno grossi vantaggi proprio se utilizzate in parallelo, in sequenza diventano solo un'altro tipo di FVG. Un'altro vantaggio rispetto alle FVG è che alle SEQ si può accedere per nome...

Vorrei poi chiarire che io non sono contro nessuno, e non sto demonizzando l'utilizzo delle FVG. Dico solo che in alcuni casi non sono la miglior soluzione, soprattutto se utilizzate in modo spinto in loop paralleli. Non trovo l'esempio pratico e purtroppo non riesco a ricreare la race condition di cui vorrei farvi evidenza nell'utilizzo delle FVG. Appena però riesco a trovare l'esempio nel sito NI vi posto il link.

Buon lavoro a tutti.

[aris]

Vorrei poi chiarire che io non sono contro nessuno, e non sto demonizzando l'utilizzo delle FVG.

Ma Riky!
Stavo scherzando!!!!!!

Siamo qui per discutere, no?!?
Ogni tipo di design ha i suoi pro ed i suoi contro, ed anche il modo in cui viene implementato può cambiare il risultato finale.

Volevo solamente dire che, nell'esempio che hai postato, credo sia difficile fare un vero e proprio confronto, nel senso che le due tipologie di design operano in modo decisamente diverso!

(mica prendertela, è?!?! )

Aris