Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
Ciao Aldo, non ho tempo di risponderti per bene, comunque riguardo alle performance ti consiglio di guardare direttamente il codice assembly generato:
https://godbolt.org/z/-BjOd7 Compilato con gcc 8 e -O1 vedrai che i codici sono esattamente identici per le tre funzioni.
Se togli -O1 cambia l'ordine invece, ma l'else non fa nessuna differenza.
La differenza di prestazioni è inesistente perché il confronto deve essere sempre eseguito per capire se andare dentro l'if o dentro l'else
Quando dico mantieni vicini i dati relazionati fra loro mi riferisco al fatto che le CPU hanno una cache: se hai 100 elementi di un tipo e 100 di un altro tipo e ci accedi tipo array1 e poi array2 stai facendo potenzialmente un sacco di accessi alla RAM e sforzando la cache.... Dovresti creare una struttura o classe che contiene il dato di tipo 1 e il dato di tipo due, ed avere un solo array di questa struttura. È un consiglio generale, che non si applica al codice da te postato, ma credo che ti sarà utile.
Lascia fuori il superfluo significa che devi valutare se ha senso salvare dei risultati di operazioni, perché se il conto richiede una somma e una moltiplicazione non ha senso salvare il risultato in RAM. Ma è solo un esempio: inline se non è assolutamente necessario non usarlo, perché è il compilatore che deve decidere se generare del codice inline o meno. Informati quali sono le ottimizzazioni che g++ può fare sul codice e non "forzarle" a mano. Esempio: g++ può fare l'unroll dei cicli. Tu scopri che per il tuo programma è conveniente.... Non fare l'unroll sul sorgente, perché potresti fare peggio e g++ potrebbe fare delle assunzioni sbagliate su ciò che vuoi fare, e quindi sbagliare ottimizzazioni.
Ci sono molte considerazioni dietro ad un programma, ma la dimensione dell'eseguibile non deve essere una di queste: includi STD::exception, ciò include <string> e quindi l'eseguibile sarà più grande, tu non vuoi ciò e quindi non lanci eccezioni e non inclusi <exception> se in un futuro ti servirà includere <string> ti troverai che comunque l'eseguibile sarà molo cresciuto e il tuo codice non è ottimale perché volevi evitare che crescesse, ma a questo punto hai codice non ottimale e un eseguibile comunque molto grande. Hai preso doppio.
Altro esempio: non crei un metodo di classe free() perché verrebbe chiamata molte volte, quindi fai free(memoria) nel distruttore e dove serve per non far fare molti call alla CPU, ma il compilatore è furbo, e ottimizzerebbe il tuo codice allo stesso modo, quindi ancora una volta avresti perso doppio: codice più complesso o meno leggibile a parità di risultato.
Ricorda che in generale tutte le ottimizzazioni che ti vengono in mente g++ le può già fare, ed è anche furbo nel farle solo quando ha senso.
Ciò che puoi fare è scegliere un pattern da seguire nei tuoi programmi, tipo lazy... Fai le cose solo quando servono e non si può più posticipare, tipo fai condivisione di memoria controllata e copi la memoria solo quando la devi modificare, e non leggere. Oppure scegli di essere safe e di copiare sempre la memoria quando copi un oggetto. Sei molto creativo e in questo campo c'è molto di più da sperimentare che nelle ottimizzazioni fatte a mano.
Invece di usare i puntatori direttamente nelle tue classi creati un template sulla base di shared_ptr che fa condivisione controllata di memoria. Pensa a come ottenere il risultato che vuoi nel modo più chiaro e con il codice più "pulito" che puoi, il resto non fa bene a nessuno: tu perdi tempo per niente e il compilatore invece di aiutarti ti rema contro.
TheDarkJuster, mi sa che tornerò domani sulle tue risposte, perché al momento ne ho capito si e no il 50% (è tardi e c'è stato il cambio d'ora solare/legale). Ci sono dei punti che vorrei capire, ma ora non ce la faccio. A domani.
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
Postato originariamente da AldoBaldo: e c'è stato il cambio d'ora solare/legale
Ma dove vivi? :-)
Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
---
Il grande studioso italiano Bruno de Finetti ( uno dei padri fondatori del moderno Calcolo delle probabilità ) chiamava il gioco del Lotto Tassa sulla stupidità.
Nessuno, ero bollitissimo del mio, fino al punto di sparare quella boiata IMMANE sull'ora legale/solare. Sii clemente. (il bello è che NON scherzavo! ma passiamo oltre, che è meglio)
Lumo, assembly so cos'è ma non ci capisco nulla.
TheDarkJuster, ti avevo promesso di rileggere le tue risposte. L'ho fatto.
Prima cosa: i consigli che mi dai NON sono riferiti al template che ho provato a fare, vero? Perché per alcuni non riesco a trovare il nesso.
La "condivisione della memoria controllata" ho capito cos'è e qualcosa di rudimentalmente simile l'ho già provato, non so con che livello di efficacia. Tu mi porti a ricordare l'esistenza degli "smart pointers", dei quali avevo letto mettendoli subito da parte perché mi sembravano una complicazione poco utile e difficilmente gestibile al mio livello. Provvederò a riprendere in mano il capitolo, anche perché da allora son passati alcuni anni e magari ora potrei provare a cimentarmici con un po' più cognizione.
Più avanti dici "non crei un metodo di classe free()..." ecc. In effetti a volte creo un metodo free() (anche se mi piace chiamarlo Dismetti() o Distruggi()), a volte no... dipende da quanto è complesso il procedimento da adottare. Se c'è solo da fare delete Questo, non sto lì a fare una funzione membro apposita, se invece c'è da spendere più passaggi in genere li "inglobo" in un metodo dedicato (di solito privato). Dunque, in breve, secondo te è una cattiva pratica creare un metodo deditato alla distruzione delle "parti" dinamiche di una classe? O intendevi il contrario? Non mi è chiaro.
"Tenere vicini i dati relazionati" è una cosa che faccio d'abitudine, anche se non ero a conoscenza del meccanismo che mi hai fatto presente (quello della cache). Il motivo per il quale l'ho sempre fatto e che trovo più semplice non "perdermi" in situazioni che in un attimo diventano dei nodi gordiani di complicazioni.
In merito alla parte dove parli di "valutare se ha senso salvare dei risultati di operazioni", avreo bisogno di casi concreti. Tipo... Metti che in una certa funzione devo fare riferimento diverse volte a un valore x*y, la mia tendenza è creare una variabile z nella quale metto inizialmente x*y per non far ripetere ogni volta il calcolo. L'intenzione è "alleggerire" l'esecuzione. Dici che è una cosa inutile o addirittura controproducente? Se ne sei certo smetto di farlo, però ti faccio questa espressione: , perché scopro una cosa che non avrei mai immaginato.
Inline: già la usavo una volta ogni morte di papa, non la userò più e buonanotte.
Unroll dei cicli: mi gratto la cocuzza, non ho idea di cosa possano essere. Vedo subito di leggere qualcosa in merito. Magari scopro che so di cosa si tratta ma non so che si chiamano così...
La cosa delle inclusioni l'ho capita. Prometto di dedicarci qualche pensiero alla prossima occasione. Vuoi una confessione? Tendo a essere C-oso (come dice Lumo) non perché "fa figo", ma perché delle librerie standard del CPP so poco poco poco, e la voglia di digerirmi il malloppone di documentazione relativa mi prende male assai. Altro che "lazy"! Super "lazy"! Sappi però che tutto quello che mi viene detto PRIMA O POI porta a modifiche del mio modo di fare, per quanto graduali, quindi grazie sia per il tempo che mi hai dedicato, sia per i consigli in se. Non cadono nel vuoto.
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
Tu prendi pure l'abitudine di dichiarare in ogni classe Distruggi(), anche se dentro c'è solo un delete. Il compilatore lo renderà inline al posto tuo se ha senso. Non ti preoccupare di risparmiare 2 byte e una call, perché il compilatore senza che tu te ne accorga, se lo lasci libero ti risparmia 4 byte e 3 call.
Detto questo.... Immagina z definito come x*y e una funzione getZ che fa: if (hasenso(z)) return z; else return z=x*y;
Una funzione del genere non ha senso di esistere: per risparmiare una moltiplicazione, ovvero 2 fetch dalla RAM di variabili già in cache e una istruzione di somma faresti un jump condizionale, un fetch dalla ram, una chiamata a funzione e se ti va male altri due fetch e la moltiplicazione. Ti ritrovi ad aver complicato e rallentato tutto, quando l'intenzione era di fare le cose velocemente.
, perché scopro una cosa che non avrei mai immaginato.