Go Down

Topic: struct (Read 375 times) previous topic - next topic

SukkoPera

#15
May 10, 2019, 02:46 pm Last Edit: May 10, 2019, 03:00 pm by SukkoPera
Ma quelli sono tutti problemi "sintattici". Immaginiamo una funzione che calcola la distanza tra due punti. Senza struct:

Code: [Select]
float dist (const float x1, const float y1, const float x2, const float y2);


Morale: 16 byte da pushare sullo stack. Con una struct:
Code: [Select]
struct Point {
  float x;
  float y;
};

float dist (const Point& p1, const Point& p2)



Morale: 2 indirizzi da pushare sullo stack, ovvero 4 byte su AVR.

In verità, è un discorso che lascia un po' il tempo che trova, perché - volendo fare le pulci - la calling convention AVR in realtà non prevede sempre di pushare gli argomenti sullo stack, e perché per accedere a y con la struct il compilatore dovrà perdere tempo a sommare un offset all'indirizzo. Per questo la verità è che il tutto dipende dall'utilizzo pratico che se ne fa. Quel che è evidente, però, è l'aumentata leggibilità che, come dicevo prima, dovrebbe essere la prima cosa da perseguire.
"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

miky_police

Quel che è evidente, però, è l'aumentata leggibilità che, come dicevo prima, dovrebbe essere la prima cosa da perseguire.
Ecco perché le preferisco in alcuni casi rispetto alle singole variabili.
Il vero stupido è colui che fa e rifa la stessa cosa aspettandosi risultati diversi. A.E.

Federico66

Tieni conto che usare (bene) le struct è un passo verso la programmazione a oggetti, che oggi è il paradigma che va per la maggiore, e che sicuramente porta grandi benefici in termini di leggibilità, mantenibilità e riciclo del codice. Questi sono gli aspetti che bisognerebbe prediligere nella programmazione, invece di ricercare l'ottimizzazione esasperata a tutti i costi. Eventuali problemi di performance si affrontano in un secondo tempo tramite profiling del codice e ottimizzazioni mirate.
Quoto in toto.

miky_police

Grazie a tutti per la partecipazione!
SukkoPera cosa intendi profiling del codice?
Come autorisposta che mi sono dato "riguardando il codice cercare di fare la stessa cosa ottimizzando risorse e tempistiche di esecuzione dei loop"...
ma è proprio questo il tuo riferimento?
Quindi non proprio adatto per guy copy & paste :D (i sarti li chiamo, taglia e cuci :D)
Il vero stupido è colui che fa e rifa la stessa cosa aspettandosi risultati diversi. A.E.

SukkoPera

#19
May 13, 2019, 10:45 am Last Edit: May 13, 2019, 10:46 am by SukkoPera
SukkoPera cosa intendi profiling del codice?
Il tutto parte dall'osservazione che a priori è difficile stabilire davvero quali parti di codice saranno eseguite più frequentemente, quindi è inutile ottimizzare tutto sempre. Ovviamente bisogna strutturare bene il programma e usare il buon senso, ma fare i salti mortali per risparmiare un bit o mettersi a scrivere parti in assembly a caso spesso risulta inutile, soprattutto se va a scapito della leggibilità, mantenibilità e portabilità, come già detto.

Una volta che il codice è completo, si valuta se ci sono problemi di performance o meno. Qualora si desideri migliorarle, si fa il profiling. Ora, non ho idea di come si possa fare nel contesto di Arduino, in ogni caso si tratta di strumentare il codice (tramite un apposito tool, mica a mano) in modo che registri informazioni su quali funzioni vengono chiamate e quando. A posteriori, si analizzano queste informazioni e si vede, ad esempio, che la funzione X() è stata chiamata miliardi di volte, quando magari ci si aspettava molte meno. Dunque si agisce di conseguenza, sistemando il problema o ottimizzando X(), che ora sappiamo essere un punto critico, cosa probabilmente difficile da prevedere.

You get the idea :).
"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

gpb01

#20
May 13, 2019, 10:55 am Last Edit: May 13, 2019, 10:56 am by gpb01
... Ora, non ho idea di come si possa fare nel contesto di Arduino ...
Credo che in Atmel Studio sia possibile fare il "Code Profiling" anche degli AVR (sicuramente per gli ARM) ... mai provato (... lo faccio in MPLAB X con i PIC), ma ho letto in giro che probabilmente usa avr-gprof ... non ho idea se sia vero e se sia possibile ::)

Guglielmo

P.S.: Probabilmente, in futuro, quando il supporto AVR sarà completato in MPLAB X, allora sarà pssibile farlo da li con i suoi strumenti ;)
Search is Your friend ... or I am Your enemy !

SukkoPera

Possibile, gprof è il tool per il profiling che si usa solitamente in compagnia di GCC.
"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

miky_police

Ottimo. Grazie a tutti, anche per le informazioni sul profiling che ne ero totalmente all'oscuro. Farò ricerche mirate per cercare di capire meglio cosa fa e come si usa. Alla prox!
Il vero stupido è colui che fa e rifa la stessa cosa aspettandosi risultati diversi. A.E.

Go Up