# [forse OT] Ottimizzare le prestazioni delle applicazioni

## CarloJekko

Senza voler fare pubblicità.. ho letto su una rivista la possibilità di acquistare con licenza da studente (ed io lo sono) un Compilatore c++ (intel c++ compiler 8.1 per linux)

La pubblicità promette integrazione con il gcc 3.4 e un incremento del 33% delle performance senza cambiare il codice... 

Ma a noi che siamo utenti gentoo (e per di più esigenti  :Very Happy:  ) e visto che ci sono parecchie applicazioni scritte in c++... potrebbe davvero essere utile?

La spesa non posso dirla.. potrei essere denunciato credo...(ci si deve registare al sito per questo)... non è elevata però lo posso dire...

Apprezzerò qualsiasi opinione!  :Rolling Eyes: 

----------

## randomaze

 *CarloJekko wrote:*   

> Ma a noi che siamo utenti gentoo (e per di più esigenti  ) e visto che ci sono parecchie applicazioni scritte in c++... potrebbe davvero essere utile?

 

Hai provato a digitare la keyword 'ICC' nella ricerca? Ci sono diversi topic (anche italiani) sull'argomento.

----------

## AlterX

 *CarloJekko wrote:*   

> Senza voler fare pubblicità.. ho letto su una rivista la possibilità di acquistare con licenza da studente (ed io lo sono) un Compilatore c++ (intel c++ compiler 8.1 per linux)
> 
> La pubblicità promette integrazione con il gcc 3.4 e un incremento del 33% delle performance senza cambiare il codice... 
> 
> Ma a noi che siamo utenti gentoo (e per di più esigenti  ) e visto che ci sono parecchie applicazioni scritte in c++... potrebbe davvero essere utile?
> ...

 

Beh sicuramente è un grande vantaggio aumentare la velocità di tutto il sistema con il compilatore intel 

ed è comunque una cosa soggettiva il volere più velocità...

Per me che sono programmatore, la velocità non è un problema, e comunque la gentoo lo è già abbastanza in normalità  :Wink:  ; è ovvio che chi sviluppo grafica, pubblicità, musica, operazioni che richiedono velocità ecc...oltre alla potenza hardware apprezzerebbero anche aumentare la velocità del software, potendolo fare con gentoo.... :Laughing: 

E' soggettivo.

----------

## .:chrome:.

 *AlterX wrote:*   

> Beh sicuramente è un grande vantaggio aumentare la velocità di tutto il sistema con il compilatore intel 
> 
> ed è comunque una cosa soggettiva il volere più velocità...
> 
> Per me che sono programmatore, la velocità non è un problema, e comunque la gentoo lo è già abbastanza in normalità  ; è ovvio che chi sviluppo grafica, pubblicità, musica, operazioni che richiedono velocità ecc...oltre alla potenza hardware apprezzerebbero anche aumentare la velocità del software, potendolo fare con gentoo....
> ...

 

balle. se crediamo alle pubblicità, windows è il sistema più stabile e sicuro del mondo, e tutti si scannano per avere una fiat punto (con tutto il rispetto per chi ha la punto)

c'è stato un thread nella LKML nel quale è intervenuto anche Rochard Stallman (scusate se è poco), dal quale è emerso che GCC è più che sufficiente per ottenere tutte le ottimizzazioni del caso, anzi... Linus Torvalds si è lamentato parecchio della lentezza delle applicazioni compilate con i nuovi GCC rispetto a quello che si otteneva con GCC 2.98. quello è stato il compilatore più veloce che l'IT abbia prodotto e le sue prestazioni non sono più state eguagliate.

la verità è che l'architettura intel-compatibile è troppo complessa e che il volerne supportare tutte le feature porta inevitabilmente all'ingigantimento dei compilatori. dal punto di vista dell'utente, invece, lo stesso programma, compilato su GCC 2.98 e GCC 4.0 è diverso: è più grande, include il supporto alle nuove tecnologie, ma non lo sfrutta (perché non l'ha sfruttato il programmatore). alla fine viene introdotto un overhead di compilazione (e di gestione del compilato) enorme.

nella possibilità poi di creare un compilatore realmente ottimizzato (come spaccia di aver fatto intel) entrano in gioco una quantità enorme di variabili che rendono vane le ottimizzazioni sulla stragrande maggioranza delle macchine. si veda il centrino del quale esistono di fatto tre versioni, del pentium 4 del quale esistono 5 versioni dello stesso core... 

morale della favola è che quel compilatore è velocissimo... sulla carta.

alla resa dei conti è poco più che uno specchietto per allodole  :Sad: 

----------

## CarloJekko

ho preso un'evaluation copy.... 

Quindi il cinsiglio è... non ricompilare tutto  :Exclamation:   :Exclamation:   :Exclamation:   :Exclamation:   :Exclamation:   :Exclamation: 

----------

## Cazzantonio

non ho capito che c'entra il titolo del topic e il sondaggio con il compilatore icc....

----------

## CarloJekko

Compilare tutti i sorgenti dei software scitti in  c++ con il compilatore fornito da intel 8.1 ottimizza le prestazioni della cpu?

----------

## .:chrome:.

 *CarloJekko wrote:*   

> Compilare tutti i sorgenti dei software scitti in  c++ con il compilatore fornito da intel 8.1 ottimizza le prestazioni della cpu?

 

io ho già risposto prima. evidentemente ci ho messo troppe parole  :Sad: 

la risposta breve è NO

----------

## assente

cmq la gran parte di software libero è in C (se non erro)

----------

## Dr.Dran

Concordo con quello detto con K.gothmog, inoltre (per fare un esempio) ho notato che anche le sole ottimizzazioni del codice mmx o 3dnow non vengono sempre utilizzate nei software multimediali e quindi a volte compilare con i flag per le estensioni multimedia per ottimizzare il codice è quasi inutile e non si avverte un incremento di prestazioni, ma solo un aumento del codice sorgente che diventa + grande e forse anche + instabile  :Razz:   :Wink:   :Laughing: 

P.S. Molte ottimizzazioni vengono addirittura scritte in assembly (vedi il kernel stesso) e poi compilate così come sono...

----------

## XstefanoX

 *Quote:*   

> la verità è che l'architettura intel-compatibile è troppo complessa

 

Concordo con questa affermazione e faccio una domanda. Sappiamo che confrontare le prestazioni di due processori non è sempre facile, perfino confrontare Athlon e Pentium. Pensate che il gcc (versione 2.98, 3.4 o 4.0) possa dare risultati migliori su un'architettura RISC come, per esempio i PowerPC che vengono montati sui Mac? Cosa mi potete dire a riguardo?

----------

## .:chrome:.

 *XstefanoX wrote:*   

> 
> 
> Sappiamo che confrontare le prestazioni di due processori non è sempre facile, perfino confrontare Athlon e Pentium.

 

in questo caso particolare sencondo me non ha nemmeno senso: le differenze sono troppo marcate per poter esprimere un confronto di questo tipo

 *XstefanoX wrote:*   

> Pensate che il gcc (versione 2.98, 3.4 o 4.0) possa dare risultati migliori su un'architettura RISC come, per esempio i PowerPC che vengono montati sui Mac? Cosa mi potete dire a riguardo?

 

senza ombra di dubbio. pensa solo a una cosa: x86 ha istruzioni a 8, 12, 16, 24 e 32 bit; solo per distinguere tra queste serve un'elettronica molto complessa, e questo va indubbiamente a carico delle prestazioni. lo stesso vale per gli operandi e i risultati delle istruzioni.

in un processore RISC, invece, tutte le istruzioni hanno la stessa lunghezza, e tutti gli operandi sono sempre nello stesso posto. solo questo fatto ha sulle prestazioni un impatto molto più grande di quando non si possa immaginare.

vogliamo citare poi un caso particolare? guardiamo le pipeline: ogni istruzione deve percorrere tutta la pipeline per essere elaborata. il MIPS (che è un RISC) r10000 ha una pipeline a sette stadi, e per intenderci è la base da cui è stato sviluppato il processore della PlayStation 1. i pentium 4 con core northwood hanno pipeline a 20 stadi  :Confused: 

----------

## Sparker

In realtà pipeline con stadi più piccoli diminuiscono la latenza ed aumentano il throughput

Il Pentium4 prescot ha una pipeline a 31 stadi  :Wink: 

----------

## .:chrome:.

 *Quote:*   

> In realtà pipeline con stadi più piccoli diminuiscono la latenza ed aumentano il throughput

 

vero. ma resta il fatto che sono molti di più, e semplificando al massimo, se serve un ciclo di clock per attraversare uno stadio (non è vero: ne servono di più) attraversare la pipeline di un CISC è molto più dipendioso che attraversare quella di un RISC, in termini di tempo.

poi è anche vero che le istruzioni RISC, essendo più semplici, richiedono, per ogni stadio, meno cicli di clock.

alla fine un RISC è sempre più veloce

 *Quote:*   

> Il Pentium4 prescot ha una pipeline a 31 stadi 

 

davvero? a me risultava fossero 20... ma non discuto. non sono molto informato su x86  :Smile: 

----------

## akiross

Umm bhe secondo me escludendo KDE/QT la maggior parte delle applicazioni e' fatta in C, e non C++, anche se senza dubbio il C++ e' una fetta non da poco...

Sta di fatto che come e' stato detto si deve comunque verificare se questo 30% in piu' sia davvero 30% in piu' (e non sulla carta, ma prendendo 1000 pacchetti e compilandoli con entrambi vedere quale rende di piu', senza flag particolari).

Secondo me se qualcuno vuole prestazioni da sparaflash e' meglio se usa gentoo preloadata in ram piuttosto che ricompilare tutto con un compilatore dai dubbi vantaggi  :Smile: 

Comunque mi era parso di capire che gcc 4 fosse parecchio piu' performante sul codice C++, e tra l'altro Apple usa gcc 4.0 nel nuovo Xcode2 (a detta di un macuser che viene all'univ con me), quindi credo che sia a buon punto.

A dire il vero non sono maniaco di performance e a me basta che le cose vadano, quindi non sono mai stato a vedere le prestazioni al dettaglio

Anche se in realta' non ho ben capito perche' la mia gentoo compilata per questo processore e' piu' lenta delle altre distro che ho provato per i386... (sia usando cflag assurde che le classiche -O2 -pipe che ho su ora. Sulla stessa macchina ovviamente). Se mi spieghi questo poi pensero' a valutare un altro compilatore  :Smile: 

Ciauz!

----------

## Cazzantonio

 *akiross wrote:*   

> Anche se in realta' non ho ben capito perche' la mia gentoo compilata per questo processore e' piu' lenta delle altre distro che ho provato per i386... 

 

secondo me dipende dal fatto che ogni applicazione andrebbe compilata con delle flag specifiche suggerite da quello che l'ha scritta... usare delle ottimizzazioni generiche porta per forza a delle ottimizzazioni generiche che impattano negativamente sulla performance comparate a delle ottimizzazioni specifiche

----------

## .:chrome:.

 *akiross wrote:*   

> Anche se in realta' non ho ben capito perche' la mia gentoo compilata per questo processore e' piu' lenta delle altre distro che ho provato per i386... (sia usando cflag assurde che le classiche -O2 -pipe che ho su ora. Sulla stessa macchina ovviamente). Se mi spieghi questo poi pensero' a valutare un altro compilatore 

 

eh...? cosa vuol dire "più lenta" in base a cosa dici questo? in base alla tua impressione?

se è così la domanda non potrà mai trovare risposta. se sei davvero interessato a scoprirlo servono una serie di test dettagliati

----------

## akiross

Cosa vuol dire piu' lenta... aspe che cerco di spiegartelo...

Hai presente quando apri openoffice compilato su una macchina, e si apre (al primo avvio) in 26 secondi, mentre se prendi la precompilata ce ne mette 20?

Oppure hai presente quando usi mozilla-firefox compilato, e ogni volta che carichi una pagina xmms si interrompe perche' la cpu schizza al 99% di utilizzo, e se usi quello -bin (che ho su ora) la cpu non fa una piega (e xmms neanche)?

Oppure hai presente quando, sempre con firefox, la versione compilata ci mette 4 secondi (o piu') per aprire il menu' dei bookmark mentre quella precompilata si apre all'istante?

Questo e' cio' che intendo per lentezza: mancanza di prontezza da parte delle applicazioni. Non e' una impressione, e' evidente che mancano i riflessi (anche se ovviamente non e' che sto con il cronometro a vedere in quanto si apre una tendina). Le cose precompilate SPESSO mi risultano piu' performanti.

Poi magari apache, php, gcc e bash schizzano rispetto a quelle di un'altra distro, ma questo non posso negarlo ne confermarlo.

Cazzantonio: dici? Mah... secondo me quando compilano i pacchetti non usano particolari flag. E comunque non dovrebbero essere nei makefile quelle flag (e quindi: non dovrebbe averle anche gentoo)?

Cioe' non mi lamento dicendo che e' lento (va quasi veloce quanto windows), ma ho come l'impressione che le altre distro siano piu' scattanti.

Non me ne faccio una ragione: quando vorro' (se vorro') una velocita' esagerata mi prendo 1gb di ram e carico tutto in ram  :Smile: 

Comunque per concludere: benchmark dettagliati non li ho mai fatti e non credo che li faro', ma cosi' ad occhio mi sembra che gentoo sulla grafica manchi di prontezza.

Ciauz

----------

## Sasdo

Quoto in pieno akiross.... anche secondo me gentoo è più lenta delle precompilate... mah!!

----------

## CarloJekko

Come si è già più volte detto, dipende dalle flags con cui si compila il sistema... 

Io che vengo  da Mandrake ti dico che con gentoo compilato dallo stage 1 con flags standard per pentium 4...  a confronto gentoo è una scheggia...

Se poi il make.conf lo "intasi" di flags è ovvio che il software compilato è più elaborato...Bisognerebbe fare un tuning... Io girando un pò su internet e da esperienze di amici sono riuscito a compilare un sistema che si avvia in 14 sec  :Exclamation:   (KDE escluso)

----------

## Dr.Dran

 *CarloJekko wrote:*   

> Bisognerebbe fare un tuning... Io girando un pò su internet e da esperienze di amici sono riuscito a compilare un sistema che si avvia in 14 sec   (KDE escluso)

 

WOW Puoi postare il tuo make.conf? A me interesserebbe moltissimo poterlo vedere e provare sulla mia macchina!  :Very Happy: 

----------

## CarloJekko

```

CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" 

USE="cups slp opengl arts avi cdparanoia cdrom divx4linux dvd dvdr \

     dvdread dxr3 ffmpeg real gimp gimpprint mmx  mp3 mpeg mpeg4 \

     mplayer nvidia avi dv esd sblive fbcon java gphoto2 hal javascript \

     kde xv quicktime sse sse2 v4l v4l2 X xine xvid win32codecs joystick \

     ogg font-server nptl nptlonly codecs -pam \

     mozdevelop moznoxft mozsvg mozxmlter"

```

poi ho seguito questo howto per altre ottimizzazioni http://wiki.gentoo-italia.net/index.php/Come_volare_con_gentoo

vedi che volerà anche a te (forse + che a me)

----------

## Dr.Dran

Hai settato pure gli LDFLAGS???

----------

## CarloJekko

no...  ho saputo che rendono tutto instabile

----------

## Dr.Dran

Infatti, ho fatto varie prove e pur aumentendo in alcue applicazioni la velocità di caricamento in altre ne impediscono la corretta compilazione...  :Very Happy: 

Grazie mille per la configurazione mi è molto di aiuto verificare per poter ottimizzare (sempre in stabilità non posso permettermi di madare a quel paese tutta la mia distro... e di conseguenza il mio lavoro!)  :Cool:   :Shocked:   :Laughing: 

Ho notato che hai disabilitato pam e hai settato slp, come mai? (scusa domanda da ignorante)  :Razz: 

per esempio io slp ho visto che è presente ma non saprei come configurarlo e a che serve? E' un helper per cups o altri software? Hai qualche doc in proposito?Last edited by Dr.Dran on Sat Apr 16, 2005 6:44 pm; edited 1 time in total

----------

## CarloJekko

invece di -03 potresti provare -02 ... che è meno "aggressivo" e rende ancora più stabile tutto

----------

## Dr.Dran

ehm... scusami ma forse con le domande di prima risultavo in pò mooooolto OT  :Razz: 

----------

## CarloJekko

slp è solo un utility per cups... stà per Service locator protocol... è utile soprattutto per un server di stampa...

Per quanto riguarda PAM... C'è chi lo installa e chi no... io l'ho tolto perchè mi dava + fastidio che altro...

Ps

Hai un'avatar carinissimo  :Exclamation:   :Exclamation: 

----------

## Dr.Dran

Grazie eh eh eh è Megaman X  :Wink: 

Un mio eroe dei tempi del mame  :Laughing: 

Capisco, ma tu l'hai configurata? Te lo chiedo visto che utilizzo cups come printer server e mi chiedevo se era utile e che cosa offriva in +... però chiedendoti questo mi sa che vado tremendamente e veramente OT!!!  :Embarassed: 

P.S. Anche il tuo TUX è carinissimo!  :Laughing: 

----------

## CarloJekko

no... non credo si setti cmq .. ti faccio sapere meglio... 

P.S. penso che abbiamo già sforato nell'OT  :Laughing: 

----------

## Dr.Dran

Per evitare casini, ho deciso di riportare un thread che avevo creato un sacco di tempo fa e che ora è finito nel dimenticatoio...

Insomma nessuno sa che fa SLP, ma se esiste c'è un motivo... beh indaghiamo e speriamo bene  :Wink:   :Laughing: 

----------

## akiross

Eh io leggendo in giro ho letto che alla fine aggiungere troppe menate non aiuta: anche se il codice viene ottimizzato diventa inevitabilmente piu' grosso -> piu' lento da caricare -> piu' memoria occupata.

Quindi ho optato per le classiche --march=athlon-tbird e -pipe, che sembrano essere un buon compromesso.

Ma provando ubuntu mi sembra che su gentoo le cose vadano a rallentatore (si bhe, e' un'iperbole... non e' cosi' evidente la differenza, pero' c'e').

Anche riguardo al 3D le performance di ubuntu sono migliori  :Neutral:  Stessa macchina, stessa scheda, stessi driver.

Saluti!

----------

## Dr.Dran

beh ritornando in tema del thread direi che sarebbe interessante controllare le cflags per i pacchetti di ubuntu. Comunque a membra che gentoo rispetto anche a winzoz sia mooolto più reattivo, si ci mette qualche secondo in più a caricarsi (circa un quindicina) ma una che entro dentro è tutto molto stabile e lavoro sempre bene.

P.S. Io utilizzo gnome come DM  :Laughing: 

----------

## Sparker

 *k.gothmog wrote:*   

> 
> 
>  *Quote:*   Il Pentium4 prescot ha una pipeline a 31 stadi  
> 
> davvero? a me risultava fossero 20... ma non discuto. non sono molto informato su x86 

 

Nella versione che hai citato tu infatti erano 20, le hanno aumentate nei core successivi (da quando hanno messo l'hiperthreading credo)

Anche secondo la mia esperienza troppe ottimizzazioni rallentano il sistema.

----------

## Cazzantonio

 *akiross wrote:*   

> Cazzantonio: dici? Mah... secondo me quando compilano i pacchetti non usano particolari flag. E comunque non dovrebbero essere nei makefile quelle flag (e quindi: non dovrebbe averle anche gentoo)?

 

Dico che le distribuzioni che funzionano a pacchetti hanno delle persone che perdono tempo a compilare ogni singolo pacchetto

Tali persone, che ovviamente conosceranno bene (meglio di me) l'applicazione che compilano, probabilmente sapranno come ottimizzare al meglio il codice, come ottimizzare il rapporto grandezza_codice/velocità etc...

Probabilmente lo sanno fare meglio di me che mi limito a usare flag generiche per tutte le applicazioni

Voglio anche far notare che ci sono flag come -Wl,--as-needed che velocizzano davvero l'avvio delle applicazioni, solo che con alcune (poche, circa una quindicina su un totale di 600 paccchetti) fanno casino e per questo nessuno le mette in make.conf

probabilmente come quella che ti ho citato ce ne sono tante, a saperle tutte e a sapere con quale applicazione usarle e con quale no probabilmente andrebbe tutto più veloce

----------

## Dr.Dran

@Cazzantonio

Credo che il concetto risiede proprio nella struttura di una distro, quelle pacchettizzate hanno tutti i pacchetti ottimizzati con le relative flag personalizzate, in portage è complicato, visto che si settano delle variabili globali che però non essendo omogenei tutti i pacchetti (nel senso che non sono stati sviluppati in ambienti uguali) a volte danno dei problemi.

L'opzione che hai detto è stata discussa, ed ha ottenuto un buon riscontro in abbinamento con l'opzione -Os nel CFLAGS e con ambienti tipo KDE, perchè io che ho gnome non ho giovato del discorso e mi sono inbattuto nel bug che ha segnalato k.gothmog!

Apro una piccola parentesi:

Continuo a sostenere che la velocità la troveremo nei nostri ambienti grafici quando uscirà una versione stabile di glitz che si appoggerà su cairo, allora avremo interfacce grafiche che utilizzeranno il processore grafico delle schede che abbiamo facendo delle chiamate dirette alle primitive opengl... veramente performante (P.S. Ho visto un pò di cosine da un mio amico che ne ha una versioncina sperimentale installata)  :Shocked:   :Laughing: 

Infatti se operiamo solo da console basta seguire la guida "Come volare con gentoo" e si ha a disposizione un sistema super performante"

Ciauz  :Very Happy: 

----------

## .:chrome:.

 *DranXXX wrote:*   

> Credo che il concetto risiede proprio nella struttura di una distro, quelle pacchettizzate hanno tutti i pacchetti ottimizzati con le relative flag personalizzate, in portage è complicato, visto che si settano delle variabili globali che però non essendo omogenei tutti i pacchetti (nel senso che non sono stati sviluppati in ambienti uguali) a volte danno dei problemi.

 

trascuri un fatto: le distribuzioni pacchettizzate NON SONO OTTIMIZZATE e non hanno flag personalizzate, e la spiegazione è presto data: devono essere compatibili con la maggior parte delle piattaforme, quindi non si possono permettere di adottare ottimizzazioni per una specifica piattaforma, quindi tutto il software viene compilato per una data piattaforma, considerata il limite inferiore di installazione, e con nessuna flag specifica di compilazione.

RedHat e debian compilano per i386, slackware per i486, OpenNA (clone RedHat) e ubuntu compilano per x586. Il massimo che si possono permettere di fare è utilizzare delle facility scritte ad-hoc per il proprio sistema, ma non molto di più.

----------

## neryo

 *k.gothmog wrote:*   

> 
> 
> trascuri un fatto: le distribuzioni pacchettizzate NON SONO OTTIMIZZATE e non hanno flag personalizzate, e la spiegazione è presto data: devono essere compatibili con la maggior parte delle piattaforme, quindi non si possono permettere di adottare ottimizzazioni per una specifica piattaforma, quindi tutto il software viene compilato per una data piattaforma, considerata il limite inferiore di installazione, e con nessuna flag specifica di compilazione.
> 
> RedHat e debian compilano per i386, slackware per i486, OpenNA (clone RedHat) e ubuntu compilano per x586. Il massimo che si possono permettere di fare è utilizzare delle facility scritte ad-hoc per il proprio sistema, ma non molto di più.

 

Sono daccordo con k.gothmog.. tutte le distro precompilate devono poter girare su diverse piattaforme in modo piu' o meno simile e performante, quindi vengono compilate in modo generico tralasciando le ottimizzazioni per le specifiche architetture. Quindi rimane ancora il dubbio iniziale di cosa fa andare piu' veloce le distro precompilate!?  :Shocked: 

Sicuramente alcune ottimizzazioni specifiche, magari sempre indipendenti dalla piattaforma migliorano il tempo di risposta delle applicazioni, per cui mi sento di dare ragione anche a Cazzantonio.. il problema e' che bisognerebbe conoscere molto bene tutte le ottimizzazioni e le applicazioni che vogliamo compilare.. rimanendo il problema che fondamentalmente in gentoo c'e' una deinizione globale delle opzioni di compilazione...  :Wink: 

----------

## Dr.Dran

@k.gothmog

 *Quote:*   

> ...Trascuri un fatto: le distribuzioni pacchettizzate NON SONO OTTIMIZZATE e non hanno flag personalizzate, e la spiegazione è presto data: devono essere compatibili con la maggior parte delle piattaforme,..
> 
> ...OpenNA (clone RedHat) e ubuntu compilano per x586...

 

Mmmm... sai hai proprio ragione, infatti grazie alla tua citazione di Openna, sono andato a spolverare il manualone di Mourani e ho trovato un pochino di delucidazioni,.. dunque ho notato che non vengono mai utilizzate ottimizzazioni specifiche per le cpu, ma solo generali del tipo aggiungere in CFLAGS l'opzione -funroll-loops e -fomit-frame-pointer e in alcuni applicativi tipo i db (mysql e postgres) vengono passate alcune ottimizzazioni per il compilatore c++ quindi in CXXFLAGS viene aggiunto il contenuto di CFLAGS + queste opzioni -felide-constructors -fno-exceptions -fno-rtti. Quindi non sono ottimizzazioni specifiche sull'architettura, ma ad esempio servono per ottimizzare i cicli etc etc.

Che sia questa la chiave  :Question:   :Exclamation:   :Question: 

Purtroppo non sono un grande programmatore, quindi non so spiegare bene il significato di queste ottimizzazioni.  :Embarassed:   :Very Happy: 

----------

## .:chrome:.

 *DranXXX wrote:*   

> Mmmm... sai hai proprio ragione, infatti grazie alla tua citazione di Openna, sono andato a spolverare il manualone di Mourani

 

mmmittticcccoooooooooooo!!!! un altro mouranista!!!!  :Very Happy:   :Very Happy:   :Very Happy: 

ma sai quanto mi sono fatto le ossa grazie al buon Gerard?  :Smile:   :Cool: 

ho sfruttato così tanto quel libro che adesso ho deciso di fare una buona azione e comprarne una copia cartacea. peccato che non si decidano più a spedirmelo...  :Confused: 

ok... adesso mi scuso con la community per questo post assolutamente inutile  :Embarassed: 

----------

## Dr.Dran

eh eh eh e con chi ti aspettavi di parlare eh eh e non sono mica un bau bau micio micio qualunque eh eh eh....  :Cool:   :Laughing:   :Laughing:   :Laughing: 

Grazie a quel manuale e prima ancora alle sue versioni precedenti ho realizzato dei serverini niente male ancora on-line da ben + di 5 anni eh eh eh... non male evero?!?  :Laughing: 

(Pensa da server www/ftp a web director a mail/pop3/imap e sono ancora online eh eh eh)

Associo le mie scuse con quelle di k.gothmog alla comuniti per la risposta inutile al post inutile  :Embarassed: 

----------

