Newsgroup: it.comp.lang.c++
Titolo: Velocità programma C++ e VB.net

Se ho capito bene, un codice scitto in C++ � pi� performante rispetto allo 
stesso codice scitto in VB, C#  o Python, � meno performante rispetto a un 
codice scritto direttamente in linguaggio macchina.
Quando compiliamo il programma, e quindi otteniamo il file .exe, non 
traduciamo il nostro codice, da linguaggio di alto livello, in linguaggio 
macchina?
 In poche parole, perch� l'eseguibile "proveniente" da C++ � pi� performante 
rispetto allo stesso eseguibile "proveniente" da VB, C# o Python?
Ciao
nero

 avete info sulle DLL bene uguale)
no, il linker include tutto questo perch� non pu� predire tutte le 
tipologie di chiamate. In quanto, come ben sai, con il c++ puoi usare i 
puntatori a funzione per tale motivo il linker include tutto. Tale 
esperienza la ho maturata su gcc e quindi mi aspetto che sia rispettata 
anche su altri compilatori.

 anche su altri compilatori.
eh ... quindi quando si usano librerie giganti per fare cose 
da poco, si paga pegno ...
ciao
Soviet

 
paghi un piccolo pegno, ossia la dimensione dell'eseguibile se � lincata
staticamente, altrimenti la dimensione della libreria di runtime se �
caricata dinamicamente, ovviamente in memoria viene caricata pi�
velocemente una libreria di 200k che non una di 20mega ma a meno che tu
non sia su un sistema embedded non ne vedrai la differenza.

 non sia su un sistema embedded non ne vedrai la differenza.
Mah ... sul mio con 1 GB di ram la vedo. Quando parte 
Firefox (schiatti SQLite), lascia le briciole per gli altr 
programmi, e già mi accorgo che i programmi datati un dieci 
anni partono lisci, i pesantoni moderni macinano.
Certo, quando cambierò il PC non me ne accorgerò più. Pare 
la soluzione caldeggiata da tutti quanti, produttori di SW e 
di HW
ciao
Soviet

 
Stavamo parlando di un programma compilato in C++ che chiamava delle
funzioni in librerie a caricamento dinamico, non di applicazioni che si
tirano su una macchina virtuale pi� relativo framework.
Mi sembra strano che tre software diversi tirino su 3 macchine virtuali
.net visto che la 3.0 � retrocompatibile fino alle 2.0, ma non avendo
macchine windows non so che dirti. Ovviamente se apri un applicazione
java, e una .net ad esempio ti tiri su 2 virtualmachine con relativi
thread per il garbage collector, relativi jit eccetera.
Il pegno di usare librerie omnicomprensive (tipo wxwidgets o qt) �
piccolo proprio perch� eseguibili compilati nativi hanno bisogno solo
delle librerie a collegamento dinamico necessario.
Facciamo un esempio, penso ad una macchina windows che mi sembra ti sia
pi� familiare se il framework � fatto bene, tipo qt, hai varie dll =>
qt4core, qt4gui, qt4sql, etc... quindi una tua applicazione compilata
statica, mettiamo un frontend ad un database utilizzer� solo le dll
core, gui e sql e quelle il sistema caricher� in memoria lasciano
perdere ad esempio opengl, network etc... Quindi il pegno � piccolo.
Ancora meglio quando utilizzi molte applicazioni che usano le stesse
librerie, ad esempio sotto linux tutte le applicazioni kde usano qt4 e
tutte le applicazioni gnome gtk (+ o -, ma stiamo semplificando) quindi
a monte di poche librerie in memoria hai molte applicazioni che ci si
"collegano".
Non ha senso paragonare linguaggi che usano virtual machine e affini ai
linguaggi che creano un binario nativo perch� anche se cache e jit
possono fare miracoli e di fatto il recupero in termini di performance �
buono, avere comunque un garbage collector, reflection e altri
meccanismi di runtime portano ad avere un tempo di sturtup pi� lento
(deve caricare prima la vm, avviare i suoi servizi e poi caricare la tua
app) sia un consumo di memoria maggiore. il gc � thread low priority per
avere performance decenti, inoltre vengono sempre finalizzati oggetti
piccoli perch� creano pi� frammentazione e quindi l'occupazione della
memoria tende ad essere elevata con frequente paginazione, accesso al
disco, rallentamento dell'applicazione.
in soldoni cos� �.

 statico, ma se avete info sulle DLL bene uguale)
I linker che non siano dei gicattoli, il controllo delle dipendenze
lo fanno da tempo immemore.
Tanto per darti dei numeri: alcune librerie statiche di wxwidgets
wxBase.lib, se non erro sono grandi anche piu' di 20 mega. Un
programma di media compessita' (che quella libreria la linka
sicuramente come tutti i programmi basati su wxwidgets), FlameRobin
ad es., linkato staticamente e' grande un paio di mega.
C:\>iao Angelo

 C:\>iao Angelo