Newsgroup: it.comp.lang.c++
Titolo: Fine di un mito?

Ho realizzato dei Benchmark, una stessa applicazione scritta in
linguaggi diversi (C++, Delphi, Java, C#, 
VB.NET
).
I risultati sono stati sorprendenti.
I linguaggi hanno prestazioni diverse da quelle che uno si immaginerebbe.
Riporto qui il link, fatemi sapere cosa ne pensate.
www.alessandropulvirenti.it/programmazione/
Grazie e Ciao
-- 
Alessandro Pulvirenti

 
www.alessandropulvirenti.it/programmazione/
Penso che i linguaggi interpretati abbiano un grande vantaggio rispetto 
a quelli compilati: possono ottimizzare il codice in tempo reale in modo 
adattivo.
Il punto debole dei linguaggi di quarta generazione è il garbage 
collector, ma ultimamente si stanno escogitando algoritmi sempre più 
efficienti. Così come piano piano il C è diventato più veloce 
dell'assembly, penso che Java e compagnia diventeranno più veloci del C 
e C++.
In generale, più cose sono lasciate al compilatore, più è possibile 
ottimizzare il software. I compilatori C++ non sono migliorati come i 
compilatori (JIT) di Java e altri linguaggi interpretati, in questi 
ultimi anni.
Comunque un solo test o vari test basati su una sola tipologia di 
software non bastano.
Kiuhnm

 
www.alessandropulvirenti.it/programmazione/
Bisognerebbe vedere il codice prima di commentare.
Per quanto riguarda gli SO la cosa quasi non mi meraviglia, ME è fa parte
della categoria W9x e qui molto basata su DOS il quale da buone prestazioni
ad applicazioni "cucciaprocessore". Prova a lavorare con processi
multithread o multiprocesso e poi vediamo.
Bye,
Raktzo

 software non bastano.
Queste sono le uniche due cose giuste che avete detto...
...il resto, beh... ;-)
-- 
Qual'e' il colmo per uno studente-lavoratore?
Avere un quadrato che si crede un rettangolo.

 Riporto qui il link, fatemi sapere cosa ne pensate.
YAUP
Senza offesa č... (Yet Another Useless Page).
Hai preso un'applicazione particolarissima. Hai scelto OS non si sa con
quale criterio... Per esempio, perchč SuSE 8 (con il Kernel 2.4, immagino e
non una moderna distribuzione?).
Che senso ha mettere dentro ME? E DOS?
Insomma... non capisco perchč vuoi provare i "linguaggi" e poi fai cosě
tante prove "indipendenti dal linguaggio"... Boh
-- 
USB Priests for only 10$

 ...il resto, beh... ;-)
Ho appena trovato qualcun'altro che la pensa come me:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Kiuhnm

Francesco Monica ha scritto:
[...]
http://www.bytonic.de/html/benchmarks.html
E' comunque veramente sbagliato dire che Java ha raggiunto il C++.
E' facile capire l'errore.
Immaginate prima un programma scritto in C++ che allochi memoria n volte 
e la deallochi altrettante volte e poi un secondo programma ottenuto dal 
primo eliminando tutte le deallocazioni.
Se la memoria fisica è sufficiente a contenere la "memoria di lavoro" 
del programma, la seconda versione andrà più veloce (difficilmente la 
cache farà la differenza, a patto che il programma non salti da una zona 
all'altra della RAM).
Il GC ricorda la seconda versione.
Questo spiega perché Quake 2 va tanto veloce anche in Java.
Cosa succede però se la memoria è appena sufficiente per un'applicazione 
ben scritta in C++? Succede che il programma in Java è lentissimo.
Riuscite a immaginarvi F.E.A.R. o Call Of Duty 2 in Java?
Alcuni diranno che la RAM costa sempre meno quindi se ne può avere 
sempre di più. Questo è vero. La cache memory però costa molto e pone 
vari problemi. Se in un sistema operativo vengono eseguite molte piccole 
applicazioni Java, i problemi diventano ancora più evidenti.
E' probabile che in questo caso la memoria richiesta sia di molte volte 
superiore a quella richiesta dalle stesse applicazioni scritte in C/C++.
E allora peché non un Java senza GC?
Perché non sarebbe possibile gestire le risorse elegantemente come in 
C/C++ (v. RAII).
Kiuhnm


Meglio di altri, ma anche questo e' incompleto e un po' di parte. Le
prime osservazioni/obiezioni che mi vengono in mente sono:
Quanto costa la compilazione just in time? Questo comprende il costo
della compilazione in se e la raccolta delle informazioni euristiche
sugli utilizzi tipici. Posso credere che per attivita' che eseguono in
modo ripetuto porzioni di codice efficacemente ottimizzabile il JIT dia
risultati migliori della precompilazione, ma sarebbe interessante
conoscere il punto di equilibrio. Per esempio, com'e' che le
applicazioni dotate di GUI scritte in Java tendono a risultare meno
"pronte alla risposta" di applicazioni simili scritte in linguaggi
precompilati? Sono scritte male o sono le caratteristiche di utilizzo
che non permettono al JIT di compensare l'inerente inefficienza
dell'interpretazione di byte code? D'altra parte e' vero che in molti
casi le applicazioni scritte in linguaggi precompilati trarrebbero
vantaggio da un approccio tipo "compila all'installazione", in modo da
grantire in modo automatico che il codice sia compilato in modo
ottimale per il computer sul quale deve girare.
La qualita' del codice. Come sono scritti i vari benchmark? Sfruttano
ciascun linguaggio al meglio? E piu' in generale, quanto costa in
ciascun linguaggio "programmare per la velocita'"? Che tipo di guadagni
permette di ottenere ciascun linguaggio applicando tecniche e/o idioms
specifici?
Posso benissimo credere che la garbage collection sia in condizione di
dare risultati migliori dell'allocazione tradizionale, gli autori pero'
si dimenticano che in C++ e' possibile allocare oggetti complessi
direttamente sullo stack, con prestazioni e vantaggi di localita'
decisamente superiori a qualsiasi meccanismo di GC. Sempre a proposito
di localita' ci sono algoritmi di GC che utilizzano una quantita' di
memoria notevolmente superiore agli allocatori tradizionali. Questo
puo' portare ad un incremento dei cache misses anche se la memoria e'
contigua. Non dimentichiamo poi che, soprattutto su sistemi
multitasking, la contiguita' della memoria virtuale non garantisce
affatto la contiguita' della memoria fisica. Anche di questo sarebbe
interessante conoscere l'impatto.
Nell'articolo e' poi menzionato il costo che si puo' pagare in C++
restituendo istanze piuttosto che puntatori, pero' si omette di dire
che la stragrande maggioranza dei compilatori moderni e' in grado di
effettuare la (Named) Return Value Optimization, annullando questi
costi.
Con tutto cio' non voglio aggregarmi alla banda di chi ritiene il C++
piu' efficiente per definizione, pero' non ho ancora trovato un
articolo che descriva il confronto in modo veramente imparziale ed
esauriente.
Ciao,
Nicola

Kiuhnm wrote:

Il punto e' che in questo newsgroup si parla di *linguaggi* e non di
*compilatori*.
Quello che Alex ha fatto e' stato confrontare differenti compilatori su
differenti piattaforme, per giunta nemmeno il programma era il medesimo. Ad
esempio credo che le librerie che gestiscono la visualizzazione (che non ha
scritto lui) non siano nemmeno lontamamente parenti nei vari casi...
A ben guardare non ha nemmeno scelto versioni particolarmente performanti
dei vari compilatori (per lo meno per quanto riguarda linux, credo).
Ragionando in via puramente teorica (parlando di linguaggi compilati o
pseudo-tali) C, C++, Java, ecc. vengono tutti tradotti in assembly, quindi
non e' nemmeno tanto corretto dire "piano piano il C č diventato piů veloce
dell'assembly" ecc.
La frase "il linguaggio x e' piu' veloce del linguaggio y" ha senso qualora
ci si riferisca ad alcune proprieta' del linguaggio che
favoriscono/penalizzano il compilatore nella generazione del codice
assembly (il classico esempio del vettori fortran vs C).
Pensando in questa direzione, il C++ e' molto piu' adatto a garantire
performance elevate rispetto a Java. Ovviamente un compilatore JIT Java
particolarmente performante puo' benissimo far meglio di un compilatore
scarso per il C++...
Per quanto riguarda la garbage collection, beh puo' diventare veloce finche'
si vuole, ma restera' sempre vero quello che viene riportato qui:
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
Ovviamente si tratta solo di opinioni...


 ...Così come piano piano il C è diventato più veloce dell'assembly...
Ehi ehi, non bestemmiamo! :-)
Quello che è _veramente_ accaduto è che i nuovi compilatori di oggi, 
abbinati con i nuovi processori AMD e Pentium dotati di più unità 
interne di esecuzione e che quindi possono eseguire in parallelo alcune 
istruzioni, riescono a generare codice in maniera più ottimizzata di 
quanto farebbe un programmatore assembler medio. Ma un _buon_ 
programmatore assembler può sempre scrivere codice più veloce del C.
Può anche darsi che, in un futuro, le cose diventino talmente complesse 
che i compilatori Java/C++ generino codice ancora più veloce del C (ma 
ne dubito), però resta il fatto che _niente_, in linea di principio, è 
più veloce dell'assembler.
Per quanto riguarda i valori dei benchmark ho alcune perplessità: per 
esempio quando afferma che i risultati di BC5 e BC6 mostrano che "per 
aumentare le funzionalità si devono sacrificare le prestazioni" (e 
allora com'è che le prestazioni del MSVC invece non variano???).
Abbastanza scontata la differenza fra sistemi operativi, sorprendente 
l'affermazione di Java nel calcolo puro, in cui mi sarei aspettato una 
vittoria del C++ (pure qui però vorrei andare a vedere un momentino i 
sorgenti...)
Confermata con mia grande gioia la bontà dei prodotti Borland che molti 
disprezzano dicendo "Ma sono solo dei RAD... che schifo!" ^_^
C++Builder will never die! ^______^

 
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
No, è ortogonale al GC. RAII e GC possono coesistere senza problemi. 
Semplicemente il Java non lo fa.
Niente impedisce a un linguaggio di quarta generazione di servirsi sia 
del RAII che del GC.
Kiuhnm

 sorgenti...)
Anch'io.
Kiuhnm

 esauriente.
Probabilmente perché sono pochi gli esperti in entrambi i linguaggi e 
forse questi ultimi non hanno voglia d'intervenire, visti i dibattiti 
insensati di questi ultimi anni (ne ho letti parecchi in queste ultime 
due settimane).
Kiuhnm

 due settimane).
Anche perche' probabilmente hanno un sacco di lavoro interessante per
le mani ;-)
Ciao,
Nicola

 tante prove "indipendenti dal linguaggio"... Boh
I sistemi operativi, linguaggi e compilatori che ho utilizzato li ho scelti 
con il semplice criterio che ho utilizzato tutto quello che io avevo.
Ho messo i sorgenti a disposizione proprio per dare la possibilità ad altri 
di compilarli con altri compilatori e in altri sistemi operativi, anche con 
opzioni di compilazione scelte con miglior riguardo.
Io stesso mi meraviglio dei risultati e vorrei che altri potessero 
completare con altri dati, quello che ho iniziato.
La mia non è voglia di criticare, ma di conoscere per capire quali scelte 
siano le migliori.
Io programmo in C++ da molti anni e conosco alcuni lati positivi e negativi.
Il lato negativo che in assoluto NON digerisco è la presenza dei files .H (o 
.HPP).
Un'applicazione di soli 200.000 righe di codice impiega 45 minuti per essere 
compilata (durante la compilazione include i files .H e le righe compilate 
superano i 100 milioni!!) mentre lo stesso programma scritto in C# o in Java 
viene compilato in una manciata di secondi!!
----
Comunque mi fa piacere vedere che qui si discute in modo positivo.
Altri invece programmano in un linguaggio e chiunque osi evidenziare 
qualsiasi minimo difetto, viene criticato aspramente.
Sono quelli che manderebbero al rogo chi dice qualcosa di diverso dalla loro 
religione (linguaggio).
Aspetto ulteriori suggerimenti.

 le mani ;-)
Probabile.
Una curiosità. Da dove "vieni"? Dal C o da qualcos'altro?
Kiuhnm

 qualsiasi minimo difetto, viene criticato aspramente.
Una volta ho osato criticare su comp.c++ il fatto che in C++ non è 
consentito il forward referencing, cioè non è possibile scrivere
class A
{
   B *b;
};
class B
{
};
In questo caso è facile correggere invertendo l'ordine o aggiungendo un 
semplice "class B;", ma in un progetto molto complicato (era 
praticamente scritto in C, ma compilato in C++) ho addirittura dovuto 
spostare una classe in un file header esterno (scelta concettualmente 
assurda).
Il programma era (ed è) ben strutturato. Semplicemente non è sempre 
possibile, senza rinunciare all'efficienza, isolare completamente le 
classi. Nel mio caso poi l'efficienza era tutto.
Ho risposto a un po' di critiche poi ho lasciato perdere perché sembrava 
che non leggessero neanche quello che scrivevo.
Devo ammettere che a volte posso essere un po' brusco, ma pare che su 
questo ng siate più tolleranti.
Kiuhnm

 programmatore assembler può sempre scrivere codice più veloce del C.
E come la mettiamo con la portabilità :-P
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 No, č ortogonale al GC. RAII e GC possono coesistere senza problemi. 
Che possano coesistere ne sono convinto, che lo possano fare senza
problemi non piů di tanto...
Ciao


 
E' proprio su questo punto che non sono d'accordo.
Premetto che non ho visto i sorgenti, quindi quello che dico è tutto da 
verificare.
Ma IMO il design di un SW NON è indipendente dal linguaggio. Per non 
parlare dell'ottimizzazione.
Mi spiego:
Cosa vuoi misurare? Ci sono linguaggi che sono ideali perché la 
produttività del singolo programmatore è messa in primo piano. In questo 
caso la misura andrebbe fatta definendo una serie di "problemi", ben 
specificati e risolvibili, diciamo, con un paio di mesi di lavoro da 
parte di un singolo programamtore. Poi prendi una 20na o più di 
programmatori per ogni linguaggio, gli dai le specifiche, e li metti al 
lavoro. Se ti interessa misurare anche la manutenibilità (oltre che la 
pura produttività) puoi anche decidere che ogni 5 giorni verrà preso 
l'intro lavoro svolto fino a quel punto e "passato" ad un altro 
programmatore affinchè continui (senza che ci possa essere comunicazione 
fra il primo e il secondo programmatore). Valuta quanto tempo ci si 
impiega, in media, ad arrivare ad un programma funzionante a specifica e 
se (e quali) cose non sono state implementate nonchè se e quali 
funzionalità aggiuntive (non richieste) sono state aggiunte. Se fai 
questo tipo di esperimento è molto probabile che, per esempio, Python e 
Ruby, risultino molto "meglio" di Java e C++.
Ma la maggior parte dei confronti, e anche quello che fai tu, misurano 
la velocità di esecuzione del programma.
Se vogliamo fare questa misura allora, secondo me, dobbiamo tenere conto 
di alcune cose:
1) nella maggior parte dei programmi la velocità di esecuzione non è 
importante. Quindi ci serve un programma in cui la pura velocità di 
esecuzione SIA importante.
2) Devono essere ben definiti i parametri di funzionamento. Per esempio 
un programma di "simulazione atomi" (nota: invento dato che non ho visto 
il programma e non ho idea di che cosa faccia) in cui è possibile 
simulare un numero indeterminato di atomi di un numero indeterminato di 
tipi per un numero indeterminato di cicli è intrinsecamente diverso 
dallo stesso programma scritto per simulare un solo atomo di un tipo 
predefinito e per un numero di cicli conosciuto. E soprattutto è molto 
diverso il modo in cui si esegue l'ottimizzazione del programma!
3) deve essere chiaro l'environment. Presenza o assenza di più 
processori, presenza o meno e dimensione delle cache, dimensione della 
RAM etc.
Inoltre non ha molto senso, se vogliamo misurare la velocità di 
esecuzione e basta, utilizzare un programma scritto in un linguaggio e 
poi "tradotto" in un altro linguaggio.
Sono convintissimo che in moltissimi casi Java è più veloce di C++. Ma 
anche che in quasi tutti questi casi è possibile ottenere in C++ 
prestazioni molto vicine o superiori a quelle ottenute in java, SE IL SW 
E' SCRITTO APPOSTA per ottenere questo risultato.
Se e quando avrò tempo proverò a dare un'occhiata ai sorgenti del 
programma e vedere se è progettato per essere veloce o meno, se è 
progettato in Java e tradotto in C++ o viceversa e altre cose del genere.
Ma per tornare alla mia obiezione iniziale:
 > Ho preso un'applicazione che fa due cose:
 > 1) esegue calcoli;
 > 2) utilizza la grafica.
Sei sicuro? Quindi è corretto dire che l'applicazione non alloca ne 
disalloca memoria salvo in maniera assolutamente secondaria rispetto a 
"eseguire calcoli e utilizzare la grafica"?
Ho qualche dubbio.
Perché si da il caso che se una applicazione alloca e disalloca molti 
oggetti, il modo "normale" di programmare in Java è vantaggioso. Il modo 
"normale" di programmare in C++ è penalizzante.
Qualcuno ha replicato al tuo OP dicendo che uno degli svantaggi di Java 
è la GC.
Non sono d'accordo. In molti, moltissimi, casi la GC è un vantaggio.
Un mostruoso vantaggio, in termini di velocità di esecuzione.
A scapito, naturalmente, della prestazione "real time".
A

 qualsiasi minimo difetto, viene criticato aspramente.
No guarda... se parli di me come di "talebano" C++ hai sbagliato persona :)
Io semmai sarei più identificabile come python fanboy. Anche se al momento
sto prendendo una bella sbandata per Ruby. 
C++ lo uso, mi piace, ma ne farei anche a meno ;)


 
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Ti ringrazio per il link. E' una di quelle cose che torna "preziosa" nelle
discussioni con certe persone ;)


 precompilati?
Non saprei dire, perň ho notato anche altre cose.
Java + Cocoa (libreria scritta in ObjectiveC): non significativamente piů
lento che ObjectiveC + Cocoa
Python/Ruby/Perl + Cocoa: come sopra
Python/Ruby/Perl + Tk (quindi con una libreria grafica scritta in Tcl):
molto ma molto piů veloci di Java + Swing (ma fa un po' pena la gui eh... )
Python/Ruby/Perl + QT/GTK: non ho notato sostanziali differenze rispetto a
sw scritto in C++ con le stesse librerie grafiche.
Il dubbio che mi viene č che Swing sia un peso massimo di suo. Purtroppo
fuori da MacOS non ho usato SWT, quindi non so dire come siano le
performances.


 problemi non più di tanto...
Be', il linguaggio D ne è la prova. E' anche disponibile un ng apposito 
per discutere del linguaggio D.
Kiuhnm

 linguaggi/compilatori si comportano con tali caratteristiche.
Mc Osten qui ha già parlato anche per me: "la grafica" non è una, ci 
sono tanti modi diversi di fare grafica anche sulla stessa piattaforma, 
figuriamoci fra piattaforme diverse. Le differenze nei bench grafici non 
sono riconducibili ai linguaggi se non in piccola misura, IMHO.
Per testare la velocità di esecuzione dei vari linguaggi dovresti 
prendere un compito semplice, che non richieda (per quanto possibile) 
librerie nè chiamate di sistema, e che sia CPU-intensive: per 
accelerare, mettiamo, i dischi i compilatori possono fare ben poco... 
non a caso i programmi benchmark più comuni sono il calcolo di PIgreco, 
Sievert, Eratostene ecc.

 dell'interpretazione di byte code? 
Chiedo scusa per l'intrusione :P Sono un lurker javista molto 
interessato al C++ :)
Il motivo della scarsa prontezza di molte GUI scritte in Java è proprio 
che in genere sono scritte male, a causa soprattutto della intrinseca 
complessità di swing. In particolare la maggior parte dei programmatori 
non è perfettamente (o per nulla) a conoscenza del meccanismo dell'EDT 
(Event Dispatching Thread), e spesso inserisce codice "business" nel 
thread che invece si dovrebbe occupare esclusivamente della grafica.
Viceversa le applicazioni sviluppate bene con swing sono molto 
responsive: un ottimo esempio di applicazione swing *molto* ben fatta è 
il client P2P LimeWire.
La prossima versione del JDK mira comunque a velocizzare anche le app 
scritte non benissimo, e chi ha modo di provare la versione Beta può 
constatarlo.
Ciao a tutti
M.

 del RAII che del GC.
Certo che possono coesistere, pero' questo e' fattibile ammettendo la
possibilita' di avere oggetti ad allocazione automatica, cioe' nello stack.
Quello che impedisce di fatto RAII (e che porta anche ad un po' di
inefficienta a mio parete) e' imporre di applicare GC sistematicamente a
*tutti* gli oggetti dell'applicazione.
Francesco.


 Una curiosità. Da dove "vieni"? Dal C o da qualcos'altro?
Il mio percorso professionale e' abbastanza peculiare. Ho iniziato come
sistemista. Poi quando mi sono stufato di attivita' la cui portata
massima erano un paio di giorni mi sono spostato sullo sviluppo di
software. Pero' ci sono entrato da analista/project leader; quando mi
sono reso conto di quanto mi mancava tenere le "mani in pasta" ho
cercato situazioni in cui poter anche sviluppare.
Ho cominciato a programmare in Pascal e poi in C, ma a titolo
professionale ho programmato solo in C++ e in ksh, piu' un pochino di
Python.
Ciao,
Nicola

 pero' se pian piano java diventa sempre piu' simile al C++... :-)
In effetti anziché aggiungere funzionalità, bisognerebbe rendere più 
flessibili quelle già presenti, altrimenti tanto vale importare codice 
scritto in C++.
Kiuhnm