# Velocizzare il codice **URL:** \ **Category:** Uncategorized\ **Created:** [1 Ottobre 2017, 3:26pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810 "2017-10-01T15:26:28Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![rossimelthomas](https://forum.olinfo.it/letter_avatar_proxy/v4/letter/r/d26b3c/32.png) [@rossimelthomas](https://forum.olinfo.it/u/rossimelthomas)\ **Post date:** [1 Ottobre 2017, 3:26pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/1 "2017-10-01T15:26:28Z")
Ciao a tutti, Oltre al fast I/O conoscete qualche altra tecnica per velocizzare il codice? ---
**Author:** ![frakkiobello](https://forum.olinfo.it/user_avatar/forum.olinfo.it/frakkiobello/32/2768_2.png) [@frakkiobello](https://forum.olinfo.it/u/frakkiobello)\ **Post date:** [1 Ottobre 2017, 3:46pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/2 "2017-10-01T15:46:19Z")
Da quello che so io le assunzioni dei problemi sono pensati per essere risolti senza fast I/O e quindi sarebbe meglio evitarli per evitare un risultato più “sincero” . Per velocizzare esistono i vari “trucchetti” che si possono usare ovunque come “\n” invece di endl in output multipli ---
**Author:** ![rossimelthomas](https://forum.olinfo.it/letter_avatar_proxy/v4/letter/r/d26b3c/32.png) [@rossimelthomas](https://forum.olinfo.it/u/rossimelthomas)\ **Post date:** [1 Ottobre 2017, 4:02pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/3 "2017-10-01T16:02:46Z")
Giusto, anche il \n velocizza di molto il codice, una volta addirittura non ho preso 100 a causa dell’endl. In ogni caso, molti per l’I/O utilizzando anche delle funzioni più lente e quindi la classifica è per forza poco veritiera. Ad esempio in passato ho utilizzato il freopen che, da solo, rallenta di molto l’esecuzione. In ogni caso il post l’ho fatto per curiosità e forse a qualcuno può essere utile per fare 100/100 😀 ---
**Author:** ![frakkiobello](https://forum.olinfo.it/user_avatar/forum.olinfo.it/frakkiobello/32/2768_2.png) [@frakkiobello](https://forum.olinfo.it/u/frakkiobello)\ **Post date:** [1 Ottobre 2017, 4:15pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/4 "2017-10-01T16:15:07Z")
Non era una critica la mia ahah Per l’input solitamente uso ifstream/ofstream della libreria fstrram. Per rimanere nei tempi l’anno scorso bastavano qualche struttura dati base. ---
**Author:** ![Think.Different](https://forum.olinfo.it/letter_avatar_proxy/v4/letter/t/ea5d25/32.png) [@Think.Different](https://forum.olinfo.it/u/Think.Different)\ **Post date:** [1 Ottobre 2017, 6:46pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/5 "2017-10-01T18:46:58Z")
Poi a volte potrebbe essere utile utilizzare un determinato algoritmo di ordinamento… Ad esempio in “Studio Amico” delle ABC2017 il normale `sort` della stl non va bene e si usa il `counting sort` ---
**Author:** ![dp\_1](https://forum.olinfo.it/user_avatar/forum.olinfo.it/dp_1/32/2635_2.png) [@dp\_1](https://forum.olinfo.it/u/dp_1)\ **Post date:** [1 Ottobre 2017, 8:30pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/6 "2017-10-01T20:30:02Z")
Con freopen non ho mai avuto problemi, l’ho sempre usata e ho varie soluzioni tra le più veloci. Spesso la differenza la fanno fastin/out e le versioni unlocked di getchar e putchar. Altro parametro importante sono le opzioni di ottimizzazione date a g++ durante la compilazione. ---
**Author:** ![frakkiobello](https://forum.olinfo.it/user_avatar/forum.olinfo.it/frakkiobello/32/2768_2.png) [@frakkiobello](https://forum.olinfo.it/u/frakkiobello)\ **Post date:** [1 Ottobre 2017, 9:21pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/7 "2017-10-01T21:21:08Z")
> [@dp\_1](#): > > Altro parametro importante sono le opzioni di ottimizzazione date a g++ durante la compilazione A cosa ti riferisci? ---
**Author:** ![dp\_1](https://forum.olinfo.it/user_avatar/forum.olinfo.it/dp_1/32/2635_2.png) [@dp\_1](https://forum.olinfo.it/u/dp_1)\ **Post date:** [1 Ottobre 2017, 9:32pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/8 "2017-10-01T21:32:42Z")
Al fantastico ``` #pragma GCC optimize ("O3") ``` ---
**Author:** ![frakkiobello](https://forum.olinfo.it/user_avatar/forum.olinfo.it/frakkiobello/32/2768_2.png) [@frakkiobello](https://forum.olinfo.it/u/frakkiobello)\ **Post date:** [2 Ottobre 2017, 4:47am UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/9 "2017-10-02T04:47:34Z")
Di cosa si tratta?Onestamente non l’ho mai sentito . ---
**Author:** ![dp\_1](https://forum.olinfo.it/user_avatar/forum.olinfo.it/dp_1/32/2635_2.png) [@dp\_1](https://forum.olinfo.it/u/dp_1)\ **Post date:** [2 Ottobre 2017, 9:33am UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/10 "2017-10-02T09:33:01Z")
È una direttiva da mettere prima degli include che ha lo stesso effetto di passare -O3 a g++ da riga di comando, ottimizzando il codice un bel po’. A volte con O2 o Ofast si ottengono effetti migliori, dipende dal problema. ---
**Author:** ![frakkiobello](https://forum.olinfo.it/user_avatar/forum.olinfo.it/frakkiobello/32/2768_2.png) [@frakkiobello](https://forum.olinfo.it/u/frakkiobello)\ **Post date:** [2 Ottobre 2017, 11:05am UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/11 "2017-10-02T11:05:43Z")
Ma è un istruzione che posso inserire in ogni caso e velocizza l’algoritmo indipendentemete da algoritmi/strutture usate? Riusciresti a farmi un esempio di esercizio? Grazie mille comunque😉 ---
**Author:** ![erolm\_a](https://forum.olinfo.it/user_avatar/forum.olinfo.it/erolm_a/32/514_2.png) [@erolm\_a](https://forum.olinfo.it/u/erolm_a)\ **Post date:** [2 Ottobre 2017, 1:02pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/12 "2017-10-02T13:02:54Z")
Buon pomeriggio, non tornavo qui da un po’. > [@dp\_1](#): > > #pragma GCC optimize (“O3”) Dipende. In locale non lo uso mai in quanto addio simboli di debug. Sul CMS per quanto ne sappia l’ `O3` c’è già, insieme al `-fomit-frame-pointer` e altre flag che al momento non ricordo. > [@dp\_1](#): > > Con freopen non ho mai avuto problemi, l’ho sempre usata e ho varie soluzioni tra le più veloci Un’altra possibilità è usare `ios_base::sync_with_stdio(false);` e poi usare cin e cout tranquillamente. Sospetto però che l’operator\<\< e \>\> siano più lenti di quanto dichiarato, ma non ho dati alla mano (ok, dovrebbero essere templatizzati, tuttavia la faccenda delle flag globali per la conversione bool in alpha, o la base decimale etc., il buffering e così via **devono** influire in qualche modo). Un altro motivo per cui preferire `printf/scanf` a `cin/cout` è il loro supporto alle espressioni regolari (ricordo un problema sull’Halim che chiedeva di printare la parte decimale di N numeri in ingresso, la sfida è proprio di fastI/O). ---
**Author:** ![erolm\_a](https://forum.olinfo.it/user_avatar/forum.olinfo.it/erolm_a/32/514_2.png) [@erolm\_a](https://forum.olinfo.it/u/erolm_a)\ **Post date:** [2 Ottobre 2017, 1:06pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/13 "2017-10-02T13:06:43Z")
Parlando in astratto, uso pesante della STL. Ad esempio, se devi inizializzare un vettore, usa sempre `fill`, `memcpy`, `copy`, `iota` etc. Evita gli iteratori il più possibile. Anche se lo standard mette sullo stesso piano, non credo che, ad esempio, `input_stream_iterator` sia una buona idea. Evita gli operator\<\< inutili, per il discorso di prima. Il che significa, ad esempio, evita di printare un carattere alla volta, piuttosto scrivi su una stringa. Un operatore abbastanza comodo ma che sconsiglio un poco è `sstream` (qualcuno lo conosceva vero?). ---
**Author:** ![erolm\_a](https://forum.olinfo.it/user_avatar/forum.olinfo.it/erolm_a/32/514_2.png) [@erolm\_a](https://forum.olinfo.it/u/erolm_a)\ **Post date:** [2 Ottobre 2017, 1:16pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/14 "2017-10-02T13:16:40Z")
Entrando nel dettaglio. Come ti dicevo in sede privata @rossimelthomas dovresti puntare sul vedere bottomup dovunque. Se stai facendo problemi a query, la lettura a blocco delle query e la scrittura in blocco dei risultati rende il tutto un filino più veloce (l’ottimizzazione funziona meglio se i programmi sono [CPU-bound](https://en.wikipedia.org/wiki/CPU-bound) quindi evita di “stoppare” l’algoritmo sul più bello stampando o leggendo roba). Se vuoi fai anche una sana lettura sul funzionamento intrinseco di [CPU cache](https://it.wikipedia.org/wiki/CPU_cache) e di [località spaziale e temporale](https://en.wikipedia.org/wiki/Locality_of_reference). Se poi approfondissimo ci sarebbe anche la faccenda dell’allineamento, o il branch prediction, ma esuliamo dall’aspetto competitive. Un ultima cosa va detta: **O(logN) non è necessariamente meglio di O(N)**! Conosco gente che costruisce delle map per convertire poche chiavi in pochi valori anziché fare switch/case. Fidatevi, ce ne vuole prima che la differenza conti qualcosa. ---
**Author:** ![rossimelthomas](https://forum.olinfo.it/letter_avatar_proxy/v4/letter/r/d26b3c/32.png) [@rossimelthomas](https://forum.olinfo.it/u/rossimelthomas)\ **Post date:** [2 Ottobre 2017, 1:29pm UTC](https://forum.olinfo.it/t/velocizzare-il-codice/4810/15 "2017-10-02T13:29:06Z")
Eh si lo so che è molto meglio una bottom-up, però mi vengono molto più naturali le top down. Devo allenarmi ancora molto 🙂