Newsgroup: it.comp.lang.c++
Titolo: Velocità programma con le finestre

Confrontando un programma scritto in C++ utilizzando il programma 
CodeBlocks e le librerie  wxWidgets, con un programma identico ma 
scritto con Visual Studio C++, otterrei le stesse prestazioni?
 
 
Ciao
 
nero23
 


Confondi cose diverse. Codeblocks e' solo un IDE, un ambiente grafico
che ti "interfaccia" con il compilatore. Con Codeblocks puoi usare
differenti compilatori (anche il Visual C di Microsoft). La risposta
alla tua domanda..e' che non ha senso.
 
Il compilatore  diciamo di "default" e' quello che si installa con la
10.1 ed e' GCC (non nella versione MinGW ma quella TDM). Se la tua
domanda e'
 
E' piu' prestante il GCC o Visual C?
 
la risposta puo' variare da "dipende!" a "Visual C!" passando per "GCC!"
 
La mia domanda e' : Ma che ti importa?
 
Per "normali" programmi sotto Windows su hardware decenti non ti
accorgerai della differenza. Se invece scrivi programmi di simulazione
fluidodinamica (ma non credo :-) ) dovresti essere in grado di
risponderti (e magari usare il compilatore Intel con opportune librerie)
 
A proposito. Rimuovi Codeblocks 10.1 "completamente" ed installa
l'ultima nigthly build (magari quella dedicata allo sviluppo del
debugger visuale). La differenza con la 10.1 e' abissale sotto ogni
punto di vista. Solo che dovrai installare "a mano" sia wxWidgets che il
compilatore...cosi' pero' impari...
 
 
Max
 
 

 compilatore...cosi' pero' impari...
 
 
Riformulo la domanda... dato che non sono stato chiaro.
Un programma composto da finestre (form, pulsanti ...) che utilizza il 
framework 4 (e quindi con Visual Studio)  è meno performante di un 
programma scritto utilizzando le librerie wxWidgets?
Ad esempio, l'apertura di una form è più veloce a quale dei due programmi?
 
In rete leggo spesso che i programmi scritti in C++ sono più performanti 
rispetto allo stesso programma sritto con Visual Studio..
 
 
 
 
 
 

 A proposito. Rimuovi Codeblocks 10.1 "completamente" ed installa
 
versione 10.1? Io ho la 10.5
 

 versione 10.1? Io ho la 10.5
.
Rettifico, ho la 10.05
 

> ti accorgerai della differenza.
 
A cui aggiungerei, e non fa mai male ricordarlo, che "l'ottimizzazione
prematura è l'origine di ogni male"
 
buona giornata
 
-- 
Gerolamo 
 

 hai già ricevuto:
 
Se invece confrontiamo un programma scritto in C++ e uno equivalente 
scritto in C# o VB.net, il primo risulta più "reattivo"?
 
Grazie per la risposta.
 
ciao


Credo di non poter essere più chiaro di così:
N O N   C A M B I A   N I E N T E ! ! !
 
Devi valutare altri fattori!
Ignora completamente l'aspetto di velocità dell'applicativo a favore
di mantenibilità del codice, velocità di scrittura del codice,
completezza del framework disponibile, bontà della documentazione,
portabilità e compatibilità dell'applicativo, possibilità di trovare
collaboratori preparati, rivendibilità degli skill acquisiti, riusabilità
del codice, disponibilità di esempi e parti già preconfezionate e,
infine, pure il gusto personale e l'eleganza del codice scritto.
 
Solo allora, per un applicativo a finestre che gira su un normale
PC con meno di 7 anni di anzianità e in cui il grosso è dato
dall'interazione con l'utente, puoi pensare, se proprio vuoi
perdere del tempo, alla velocità dell'applicativo.
 
Abbastanza chiaro, adesso?
 
-- 
Gerolamo 
 

 rispetto allo stesso programma sritto con Visual Studio..
 
Attenzione che Visual Studio è anche un compilatore C++, non solo 
per .NET.
 
Dovresti essere più chiaro su quello che scrivi.
 
Comunque si, di solito un programma *nativo* C++ dovrebbe essere più 
efficiente di una analogo programma .NET, ma non è così banale.
 
 
Ciao  Manlio
 


 
 
In molti siti leggo (uno a caso .. 
http://blogs.ugidotnet.org/AlexP/archive/2007/12/13/90276.aspx
)
che il vantaggio di C++, rispetto a C#, è l'alta velocità di esecuzione 
del codice.
 
Tralasciando l'impercettibilità della differenza (con i moderni 
computer...) esiste questa differenza?
 
La differenza non è dovuta al fatto che uno è compilato e l'altro 
interpretato e quindi richiede più tempo prima che si apri una fotm?
 
 
 
 
 
 
 
 

 computer...) esiste questa differenza?
 
Credo che tu voglia sentirti rispondere di si, per cui:
 
SI, con le opportune ottimizzazioni, è molto probabile, ma non certo,
che si possa fare meglio scrivendo codice nativo, invece che passare
da .NET.
 
-- 
Gerolamo 
 

 interpretato e quindi richiede più tempo prima che si apri una fotm?
 
.NET **non** è interpretato. Stai facendo confusione, vedi:
http://it.wikipedia.org/wiki/Linguaggio_interpretato
 
 
 
.NET è compilato (di default compila in byte code portabile, ma mi sembra 
sia possibile compilare direttamente in codice nativo - ovviamente così 
perdi la portabilità); per i programmi compilati in byte code esiste 
possibilità, tramite JIT (Just in Time Compiler) di compilare parte del 
programma in codice nativo durante l'esecuzione del programma stesso.
 
 
Ciao  Manlio

Secondo me la tua domanda è troppo vaga.
Programmo in c/c++ e c# da anni e la risposta più corretta che mi viene 
in mente è questa:
 
Il codice nativo è sempre più veloce di quello interpretato o compilato 
in tempo reale come java o .Net
I framework introducono sempre uno strato in più tra te e la macchina 
maquindi rendono il codice più lento.
 
In pratica però è tutto l'opposto, più ti avvicini al cuore della 
macchina più le tue conoscenze sulla programmazione e sull'hw devono 
essere avanzate.
 
L'utilizzo di framework complessi come la .Net o WxWindows rendono il 
programma sicuramente più lento ma ti permettono anche di velocizzare lo 
sviluppo del codice permettendoti di concentrarti solo su quello che serve.
 
Quando tempo addietro programmavo HPC, bisognava fare i conti con 
l'allocazione della memoria, l'allineamento dei buffer, la dimensione 
della cache e ....
Ma la cosa più importante da capire ... è che un miglioramento del 1% 
del tuo algoritmo impatta molto di più che tutte le istruzioni SSE 
attualmente disponibili.
 
Io ti consiglio di lasciare stare queste problematiche di velocità 
perchè fino a che sviluppi GUI o programmi con interfaccia grafica non 
potrai mai incappare su problemi di prestazioni critiche. Io ritengo che 
un utente possa aspettare anche 1 minute se l'operazione è complessa. 
Alla fine, l'utente non riesce a fare più di 2 operazioni in 1 secondo e 
le attuale cpu ci permettono di prendercela molto con comodo
Se sviluppi servizi le cose cambiano ma in questo caso siamo fuori tema.
 
Se però adori la velocità il mio consiglio è sempre lo stesso c ben 
condito di asm. Il c++ fa già troppe cose sotto il cofano che rallentano 
l'esecuzione del codice.
 
Buon lavoro


 Buon lavoro
 
 
Grazie

 Grazie
 
 

 Se uno usa il C++ alla C, è possibile che poco di questo sia pertinente.
 
 
Quindi il C è molto più performante di C++...
 
ciao
 

 pian piano siamo arrivati al MOLTO !
 
Tranquillo... anche qui arriverï¿œ a "E' la risposta che mi aspettavo."
 
Non credo che voglia sapere altro
 
-- 
Gerolamo 
 

 programma in codice nativo durante l'esecuzione del programma stesso.
 
In .Net non è possibile compilare direttamente codice nativo (o per lo 
meno il compilatore Microsoft non lo fa, non so quello di mono). C'è 
un'utility del framework che si chiama ngen che crea l'immagine nativa e 
la conserva in una sua cache. Quello che fa in pratica è eseguire il JIT 
e memorizzare il risultato. In ogni caso dato che il JIT è automatico 
all'avvio di ogni eseguibile ngen non migliora le prestazioni del 
programma in sé, abbrevia solo i tempi di avvio.
 
Inoltre il file generato da ngen (recuperabile con un po' di buona 
volontà dalla sua cache sepolto nei meandri di %windir%\assembly) non è 
in alcun modo utilizzabile direttamente, anzi non è proprio nel formato 
exe o così sostiene windows se provi a lanciarlo a mano...
 
-- 
r--r--r--

 Soviet
 
 
Più o meno è quello che volevo dire.
In pratica l'utilizzo di strumenti orientati ad oggetti ti porta a 
scrivere codice molto pratico da gestire ma a causa dei concetti di 
pubblico/privato, ereditarietà, interface ... tendi ad astrarre il 
codice. Tale attività è indispensabile per i grandi progetti, ma sei 
vuoi fare un programma che macina bit rendono meno preformarti il 
programma stesso.
Ribadisco che questo è un'estremizzazione del concetto stesso che lo 
puoi vedere solamente dove non hai risorse tipo ARM a 60MHz cpm 10kb di ram.
 
Cordiali Saluti
 
 
 
 

 programma in sé, abbrevia solo i tempi di avvio.
 
Non è del tutto preciso, in .Net è possibile compilare direttamente in 
codice nativo a patto di utilizzare un compilatore non nativo MS come 
Mono. Ad esempio è disponibile il compilatore per architettura ARM.
Ho provato solo una volta per curiosità e funziona.
 
Cordiali Saluti
 
 
 


 
Indipendentemente dalle prestazioni e dalle preferenze personali!
Ritengo che OOP sia la chiave di successo di un linguaggio moderno.
Non ha senso parlare di ASM -> C -> C++ -> C# ma bensi di evoluzione 
temporale ideale per architetture attuali.
Su un chip da 8bit con 4k di ram il c++ è inutile quanto il c#
Su una macchina da 64bit con 1GB di ram sicuramente sono più "agili" 
linguaggio come c# e c++. Ma  se scrivi in asm scoprirai prestazioni mai 
viste anche se del tutto inutili se valutate le ore che hai investito 
per sviluppare il codice!
Questo lo scrivo da amante degli HPC e dei microcontroller.
 
Cordiali Saluti

 Cordiali Saluti
 
 

 maquindi rendono il codice più lento.
Qui io farei una distinzione.
Se parliamo di codice "elementare", che implementa un algoritmo di 
calcolo tramite operatori diretti più che chiamate a funzioni di 
libreria, allora sono quasi d'accordo, dove il "quasi" si riferisce al 
caso JIT, in cui secondo me non c'è differenza netta.
 
Se invece parliamo di codice che si appoggia su chiamate a complesse 
funzioni di un framework di base (come è il caso per l'interfaccia 
grafica a finestre), allora ancora una volta la forbice si chiude, 
soprattutto se, come è già stato detto, la conoscenza del linguaggio e 
delle tecniche di programmazione non è sufficientemente approfondita.
 
Tanto per fare un esempio, un operazione come l'inversa di una matrice, 
implementata in un linguaggio compilato oppure un linguaggio 
interpretato, vedrà il primo in netto vantaggio . Se però nel linguaggio 
interpretato esiste una operazione predefinita per l'inversa della 
matrice, il tempo sarà circa uguale, anzi, è presumibile che 
l'operazione predefinita del linguaggio interpretato usi un algoritmo 
ottimo, e se altrettanto non viene fatto nel linguaggio compilato, 
quest'ultimo sarà addirittura svantaggiato.
 
Linguaggi come il C# (e ambienti come il .net in generale) hanno lo 
svantaggio di introdurre in runtime degli agenti che oltre a rallentare 
leggermente il codice, rendono le tempistiche molto imprevedibili. 
Tuttavia parliamo di ordini di grandezza dei tempi praticamente 
impercettibili all'utente, quindi a livello di interfaccia utente vanno 
benissimo, soprattutto alla luce di tutti i vantaggi che portano con se 
(e che sono già stati elencati). Ovviamente anche in questo caso una 
conoscenza approfondita è essenziale, per evitare di "rifare" in modo 
non ottimo, e per di più interpretato, funzioni che esistono già, e sono 
pure ottimizzate (vedi l'inversa di matrice).
 
Diverso è il caso per applicazioni runtime, in cui il millisecondo può 
essere determinante, e soprattutto è importante che sia sempre un 
millisecondo.
 
Per questo ha ancora senso di esistere il C, secondo me. Ma sono ambiti 
estremamente ristretti.
 
Se ci pensate bene, uno tra i più efficienti e robusti sistemi operativi 
esistenti, è ancora scritto in C!
 
 
-- 
Mickey

 in altro linguaggio ?
 
In realtà sì. Diversi anni fa era stata avanzata la proposta di un 
kernel linux. Solamente che Torvalds si è opposto categoricamente.
 
Mi piacerebbe dare maggiori dettagli, e magari un riferimento alla 
fonte, ma è passato troppo tempo per ricordarmi.
 
-- 
Mickey


  T
 
Ti do ragione al 100%!
Per quanto riguarda il c#, io lo trovo comodo nulla di più!
Diciamo che in certe cose tipo i delegati, lambda expression , regular 
expression , xml lo rendono molto ready to use.
Senza che mi sbatto tanto a configurare librerie c'è un po' tutto.
 

 kernel linux. Solamente che Torvalds si è opposto categoricamente.
Ovviamente intendevo un kernel linux scritto in c++. Chiedo venia per la 
svista!
 
-- 
Mickey

 interpretato e quindi richiede più tempo prima che si apri una form?
 
Se la apri in una finestra, può darsi... ma se la apri in una porta 
vedrai che è 48 volte più veloce, sia in C++ che in C#.
Credo tu sia rimasto praticamente l'unico qui a non conoscere la tecnica 
di apertura form su porta, anziché su finestra. E sì che non è da adesso 
che esiste.
 
:-D

 kernel linux. Solamente che Torvalds si è opposto categoricamente.
 
IMHO non ha torto. Il kernel di un SO si deve occupare di blocchi di 
memoria, registri I/O, descrittori di file, roba molto ben definita come 
tipo e struttura. I tipi dei dati sono quelli e amen, non c'è niente da 
riconoscere a runtime. Viceversa, il vincolo della massima velocità ed 
efficienza è stringente. Per lo scheduler e il task switcher poi è MOLTO 
stringente.
 
In più il kernel linux è già ad oggetti, anche se il C non supporta la 
OOP: Torvalds e gli altri sviluppatori hanno scritto il codice basandolo 
su degli oggetti software, disciplinandosi a usare metodi e classi anche 
se il linguaggio non li supportava. Quindi riscrivere tutto in un 
linguaggio OOP sarebbe stato uno sforzo inutile, e in più il C++ avrebbe 
imposto un costo, in termini di memoria e di velocità, rispetto al C. 
Sarebbe stato un danno, alla fine dei conti.