Newsgroup: it.comp.lang.c++
Titolo: [OT?] Compilatore Intel

Non so se è OT, comunque...
Qualcuno ha provato ad installare il compilatore C/C++ di Intel che si
sovrappone al VC++?
Io ho scaricato la versione di prova, e ho provato a ricompilare una DLL che
avevo già realizzato.
Risultati:
-Tempo di compilazione maggiore
-Dimensione finale della DLL maggiore (20K contro 14K)
-Non compilava la dichiarazione di un costruttore di copia messo nella
sezione privata e mai implementato (fatto apposta per evitarla). Togliendola
tutto OK.
Non ho potuto (ancora?) testare gli eventuali miglioramenti nelle
performances, anche perchè non so se bisogna impostare dei parametri di
compilazione particolari.
Se qualcuno ha provato il compilatore in questione, può dirmi le sue
impressioni o darmi dei consigli?
Ciao e grazie
--
Alessandro Monti

 impressioni o darmi dei consigli?
Con codice numerico spinto, avevo osservato accelerazioni di un
10-15% rispetto al miglior codice prodotto con VC++.  Inoltre, il
compilatore Intel sembrava piu` pignolo di quello MS, nel senso di
trovare (e dare errore per) piu` cose "dubbie" o errate nei nostri
sorgenti che compilava (ma forse erano solo cose _diverse_ da
quelle gia` rilevate da MSVC++ e quindi gia` rimosse:-).
Non sembrava pero` 100% compatibile con strumenti "invasivi"
di add-on a MSVC++, come NuMega DevPartner, Insure++, e simili,
per cui non ci decidemmo mai a migrare le nostre compilazioni "di
produzione" al compilatore Intel.  Non ricordo se supportava alcune
estensioni non-standard MS, come #import, che ci servirebbero.
Alex

 10-15% rispetto al miglior codice prodotto con VC++.  Inoltre, il
In effetti potrei fare delle prove in questo senso, ma dubito che mi troverò
mai a realizzare progetti più "macina-numeri" di quello corrente, e di
differenze di prestazioni non ne ho viste.
La mia idea è che, attualmente, tale compilatore riesca a sfruttare meglio
le istruzioni SIMD dei nuovi processori, a me precluse (PPRO 200), mentre
per il resto il VC++ (5.0) riesca a fare le stesse ottimizzazioni.
Per tali ragioni credo che l'acquisto di questo strumento non sia a me
conveniente, neppure in un futuro prossimo (chissà invece con Merced...), ed
in fondo era questo il mio problema.
Se la cosa dovesse interessare a qualcuno, potrei postare i risultati dei
miei confronti sulle prestazioni, ma prima dovrò anche avere il tempo di
controllare se bisogna inserire qualche parametro "strano" per spingere le
ottimizzazioni ai livelli massimi.
--
Alessandro Monti

 in fondo era questo il mio problema.
Quanto costa, oggi, questo add-on compilatore Intel...?
Il Kai CC, lo hai provato...?
Alex

Continuato per e-mail...
--
Alessandro Monti

miei confronti sulle prestazioni,
Sul mio computer (un PII 400) e' risultato produrre codice piu'
grosso, e piu' lento. Niente di scientifico o statisticamente
accettabile, comunque bench e risultati sono sul sito Papero.
-------------------------------------------------------
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

 accettabile, comunque bench e risultati sono sul sito Papero.
Visto ceh interessa...
Sul mio, in una libreria prevalemtemente matematica (reti neurali) ho
ottenuto codice più veloce.
Ho un PPRO 200Mhz, senza MMX e cose simili.
L'uso che ne faccio è tramite una DLL che uso in VFP (simile al VB per
queste cose), e ho ottenuito codice più veloce tra il 4,5% ed il 7,5%, con
punte poco significative fino al 18% (ma nei test ripetuti il singolo caso
conta poco, magari il CD che stavo ascoltando ha deciso di volere un po' di
CPU per sè :-))).
Nel mio caso d'uso reale, stimerei un vantaggio del 5% in velocità, in una
parte di codice che la sfrutta solo per il 40% circa del tempo totale, per
cui ho concluso che non rappresenta un investimento vantaggioso per me.
Mi è parso comunque di capire che Intel riesce ad ottimizzare meglio codice
"matematico" scritto in modo "pulito", ovvero senza molte ottimizzazioni già
da codice. Quando e se avrò bisogno di tanta potenza e non potrò aspettare
il chip successivo, tornerò a considerare l'idea.
Ciao
--
Alessandro Monti

sovrappone al VC++?
Io ho provato quello che Borland forniva nelle versioni 5.00 e 5.01
del Borland C++. Praticamente ha dato piu' problemi che altro. Tant'e'
che nella versione 5.02 non e' piu' incluso. Sembra che i problemi
riguardavano dei conflitti tra le opzioni di ottimizzazione del
compilatore e quelle per i Pentium del compilatore Intel.
Ma quello incluso nel VC++ ha qualche possibilita' di mandare in crash
l'applicazione appena creata?
Bye.

 l'applicazione appena creata?
Non capisco di cosa stai parlando. Solo il debugger va spesso in crash, ma
per il resto va benissimo, almeno quello...
L'applicazione creata va in crash se contiene errori, non mi è mai capitato
che fosse corretta e si piantasse perchè compilata male, con nessun
compilatore C/C++.
--
Alessandro Monti

 compilatore C/C++.
Beato te.  Il Windows Developer's Journal ogni mese pubblica
almeno un "bug++", da anni (con preferenza ai compilatori
Borland e Microsoft, i piu` diffusi -- ma non e` che gcc non ne
abbia, ahime`!-), e non pochi sono di portata tale da piantare
applicazioni corrette.  Forse hanno qualcosa anche in rete al
loro sito 
www.wdj.com
, non ricordo.
Alex

 almeno un "bug++", da anni (con preferenza ai compilatori
Beh, immagino che i bug ci siano, solo che non ne ho mai sperimentati che mi
facessero crashare il programma. Sotto windows non ho mai realizzato
programmi completi in C++, ma quando lavoravo sotto DOS ne ho fatti
parecchi, e sbagliavo sempre io :-)))
Devo dire che era un C++ meno complesso, e che il TurboC era probabilmente
il migliore. In tutto il tempo che l'ho usato ho trovato solo 1 bug "vero",
che comunque dava solo risultati errati nei conti, non un crash. Era un
problema sulla gestione di un cast esplicito, forse tra signed ed unsigned
su qualche long, ma non ricordo bene, anche perchè era risolvibilissimo con
una diversa scrittura.
Per andare in crash una volta compilato, deve esserci un bug davvero serio,
oppure essere abbinato a qualche chiamata di sistema, oppure ancora trovarsi
nelle librerie. Che sia per questo che adesso in MS stanno cercando di
mettere molta cura nel SW testing?
Ciao
--
Alessandro Monti

 Beato te.
Mi hai tolto le parole di bocca. :-)
EMG

compilatore C/C++.
Il problema e' che la stessa applicazione compilata con il compilatore
ottimizzante di Intel va' in crash mentre quando viene compilata con
il compilatore standard va' bene. La prova l'ho fatta tre anni fa
quando ricevetti l'aggiornamento alla versione 5.01 e ne ho avuto
conferma anche da alcune riviste (vi era un articolo, se non erro su
Computer Programming, in cui si confrontavano i vari ambienti IDE a 32
bit. L'articolo si soffermava sui frequenti crash dell'IDE del Borland
e del compilatore ottimizzato di Intel). Non ho purtroppo approfondito
i motivi per cui Borland ha evitato l'inserimento di tale compilatore
anche nell'ultima release.
P.S.: chiaramente con il suddetto discorso non discuto la qualita' dei
nuovi compilatori ottimizzanti di Intel che non ho, purtroppo, avuto
il piacere di provare.
Bye.

Nel mio caso d'uso reale, stimerei un vantaggio del 5% in velocità, in una
Non mi sembrano cifre significative per l'uso che sospetto tu faccia.
Il tempo maggiore l'applicativo lo passa nella DLL o dentro VFP? Il
tempo dentro la DLL in termini assoluti quanto e'? Se abbatti il tempo
da 1 millisecondo a 0.5, se non fai real time spinto, e' una
ottimizzazione non interessante dal punto di vista pratico.


 ottimizzazione non interessante dal punto di vista pratico.
Infatti, ma io non sono interessato tanto al vantaggio di usare un
compilatore piuttosto che l'altro, volevo fare un confronto in un caso
reale.
Configurando varie opzioni e piazzando bene i conteggi del tempo, posso
essere sicuro che il 90% almeno del tempo sia passato all'interno della DLL,
e ottengo un miglioramento di circa il 6,5%. Nei miei casi reali, però, ho
stimato che il tempo speso dalla DLL è circa il 40% del totale, dato che
devo gestire anche cose come l'interfaccia utente, per mostrare i risultati
parziali, dare l'opportunità di fermare la computazione, ecc.
La computazione totale potrà alla fine variare da qualche minuto a qualche
ora, e otterrei un guadagno di pochi secondi usando il compilatore Intel
rispetto al VC++, per cui non mi sembra proprio il caso. Invece è stato
significativo realizzare la libreria in C++, perchè sono passato a tempi
centinaia di volte inferiori per ogni singolo passo della computazione
rispetto alla versione in VFP. Non che non fosse un risultato atteso, dato
che VFP non è certo un "macina-numeri", ma nel frattempo ne ho approfittato
per fare un po' di esperienza e confronti tra prodotti che mi capita
raramente di usare.
Nella realtà, anche una elaborazione interamente in VFP avrebbe potuto
andarmi bene, dato che il lavoro "grosso" non deve essere fatto per forza
molte volte o con urgenza, ma per poter fare del lavoro di tuning e
debugging dell'applicazione mica potevo aspettare 3 giorni ogni tentativo,
no? E poi ho potuto tornare ad usare il C++, che per alcuni anni non ho
avuto occasione di usare (con nostalgia) e che, tra dimenticanze mie e
novità introdotte, non riuscivo neanche più quasi ad usare.
Terrò presente che comunque Intel sembra essere migliore di circa il 5% nei
tempi di calcolo, semmai ne avessi bisogno in futuro.
--
Alessandro Monti

 il compilatore standard va' bene. La prova l'ho fatta tre anni fa
Anche in questo caso, allora, mi è andata bene...
Come detto sopra, si è rifiutato solo di compilarmi un costruttore di copia
dichiarato privato e non definito, ma mi è parso di capire che proprio non
riconoscesse il costruttore di copia, non che gli importava che fosse
definito o meno.
C'è da dire anche che include una serie di "known errors" veramente
impressionante.
--
Alessandro Monti