[Java] Uso della memoria, prestazioni, vs c++

[variabilepippo]

Poi puntualmente trovi metodi Dispose chiamati male, perchè tanto c'è il GC, nessuno ha mai imparato a gestire la memoria e quindi la deallocazione corretta delle risorse

Puoi lasciare appese le risorse sia in Assembly, sia con un qualsiasi linguaggio managed. La gestione delle risorse (il tuo esempio iniziale era riferito alle connessione ad un DB) è compito del programmatore, se uno non chiude una connessione per dimenticanza, per incompetenza, per scelta deliberata o altro è colpa sua, non del GC (che è pensato per fare altre cose, non per sostituire il programmatore nella gestione delle aperture/chiusure di una connessione)! Non a caso le classi per la gestione delle connessioni prevedono metodi Open e Close.

[marco.r]

Originariamente inviato da tomminno

Il GC chiude le risorse quando esegue, ma te prova a fare delle sqlconnection e a non chiamare manualmente il dispose in maniera corretta, replica questa circostanza per migliaia di applicativi che girano intorno ad un db aziendale e vedrai l'uso corretto delle risorse che fine fa.

Quello che intendevo dire che una corretta gestione delle risorse prevede che le risorse non vengano liberate manualmente dal dispose, ma tramite altri meccanismi, o tramite un qualche oggetto responsabile (le risorse dovrebbero comunque avere sempre un proprietario) o, meglio, dallo scope.
Ad esempio in ruby puoi fare qualcosa del tipo

File.open("somefile.dat","w") {
  # Use the file here
}

e quando si esce dal blocco per qualsiasi motivo (eccezioni comprese) il file viene chiuso. In questo modo ottieni quasi tutto gratis.

[tomminno]

Originariamente inviato da marco.r

Quello che intendevo dire che una corretta gestione delle risorse prevede che le risorse non vengano liberate manualmente dal dispose, ma tramite altri meccanismi, o tramite un qualche oggetto responsabile (le risorse dovrebbero comunque avere sempre un proprietario) o, meglio, dallo scope.
Ad esempio in ruby puoi fare qualcosa del tipo

File.open("somefile.dat","w") {
  # Use the file here
}

e quando si esce dal blocco per qualsiasi motivo (eccezioni comprese) il file viene chiuso. In questo modo ottieni quasi tutto gratis.

Che è quello che ottieni per definizione dal C++, mentre in altri linguaggi hai bisogno di catene chilometriche di try finally per tutto quello che può andare storto, ovvero tutto. In C# per fortuna hanno messo lo using che evita tutto questo.
L'ultima spiaggia è il GC.

[incipit1970]

Originariamente inviato da tomminno

Che è quello che ottieni per definizione dal C++, mentre in altri linguaggi hai bisogno di catene chilometriche di try finally per tutto quello che può andare storto, ovvero tutto. In C# per fortuna hanno messo lo using che evita tutto questo.
L'ultima spiaggia è il GC.

Non esattamente: la distruzione automatica degli oggetti C++ avviene unicamente per le variabili con scope in stack. Sul heap è come Java, ma senza GC. Se fai una new e dimentichi il delete, hai esattamente lo stesso problema (senza il GC che ti corregge la fuga di memoria, però). Non per niente i programmi in C++ sono molto tendenti alle memory leaks, resource leaks e quant'altro (ci sono persino i debugger specializzati per scovare bug di quel tipo). Il GC è stato pensato appunto per correggere (in modo automatico e pertanto non ottimale) un comunissimo errore di programmazione (comune principalmente nei linguaggi unmanaged come C++). Potresti usare smart pointers, ma anche quelli hanno un costo in termini di performance.

Certo dirai che una programmazione ideale dovrebbe prendere in considerazione questi errori, e concordo. Non è certo un diffetto del linguaggio, ma del programmatore. Ma questo è un mondo imperfetto: molti programmatori commettono questi errori, quindi eliminare la causa del problema migliora, in modo economico, la qualità del programma e diminuisce i cicli di correzione errori.

Poi, per quanto riguarda la velocità delle interfacce UI in Java, hai ragione, ma non vedo il problema: Java infatti è usato bene soprattutto in ambito enterprise, dove non ha paragoni per la richezza delle librerie e di codice già pronto. Non ha molto uso nella creazione di applicazioni client (nemmeno gli applet hanno avuto grosso successo, figuriamoci un programma in AWT). Se devo fare un programma che gira su Windows, userei Visual C++, o qualcosa di simile (non andrei nemmeno su C# o VisualBasic).

Ho avuto un'esperienza con un grosso programma enterprise (un sito web) interamente scritto in C++ e CORBA, ed è una esperienza che non vorrei ripetere: non solo era lento come o più di un programma in Java o persino PHP, già solo compilare e rilasciare l'applicazione era estremamente complicato, così come il debugging. Per non parlare di problemi di concorrenzialità, locking del db, etc.

Di nuovo, ripeto: ogni linguaggio andrebbe usato nel ambito che più gli si addisce.

[marco.r]

Originariamente inviato da incipit1970

Non esattamente: la distruzione automatica degli oggetti C++ avviene unicamente per le variabili con scope in stack. Sul heap è come Java, ma senza GC. Se fai una new e dimentichi il delete, hai esattamente lo stesso problema (senza il GC che ti corregge la fuga di memoria, però). Non per niente i programmi in C++ sono molto tendenti alle memory leaks, resource leaks e quant'altro (ci sono persino i debugger specializzati per scovare bug di quel tipo). Il GC è stato pensato appunto per correggere (in modo automatico e pertanto non ottimale) un comunissimo errore di programmazione (comune principalmente nei linguaggi unmanaged come C++). Potresti usare smart pointers, ma anche quelli hanno un costo in termini di performance.

Penso che il discorso di tommino fosse ortogonale alla presenza o meno di un garbage collector. In C++ hai la possibilita' di allocare sullo stack e quindi ottenere automaticamente la deallocazione automatica all'uscita dallo scope. In linguaggi che non permettono di farlo devi fornire un mezzo alternativo (blocchi in Ruby, using in C# etc.), altrimenti gestire la cosa diventa molto complicato (come mi sembra di capire sia in Java).

Poi, per quanto riguarda la velocità delle interfacce UI in Java, hai ragione, ma non vedo il problema: Java infatti è usato bene soprattutto in ambito enterprise, dove non ha paragoni per la richezza delle librerie e di codice già pronto.

Non e' piu' un problema perche' le performance ne hanno assassinato l'uso sul lato desktop. Java e' "finito" in ambito enterprise dopo che ha fallito in altri (tra cui appunto quello desktop e client internet, dove in teoria le sue qualita' dovrebbero aver maggior risalto). Adesso la situazione e' migliorata, pero' il passato ha lasciato il segno.

Ho avuto un'esperienza con un grosso programma enterprise (un sito web) interamente scritto in C++ e CORBA, ed è una esperienza che non vorrei ripetere

E' un'esperienza che sto facendo pure io, e non consiglierei l'accoppiata C++ e CORBA neanche ad un condannato a morte

[Mixmar]

Originariamente inviato da tomminno

Veramente anche nei linguaggi managed devi deallocarti correttamente le risorse unmanaged, da una parte gestisci manualmente la memoria, dall'altra gestisci manualmente tutte le altre risorse, non ci vedo una gran differenza.

Per la mia esperienza trovo sempre colleghi che non hanno mai studiato il C/C++ che non usano correttamente la deallocazione delle risorse anche in linguaggi managed e questo a volte causa più danni di un memory leak in un singolo applicativo, tipo saturazione delle connessioni al db.

Sì, ma come hanno sottolineato altri, linguaggi managed e unmanaged condividono lo stesso insieme di problemi di "deallocazione" di risorse, solo che i linguaggi unmanaged ne aggiungono uno in più: quello della gestione della memoria (dello heap).

Forse però ti sto fraintendendo, e tu intendi dire che la mancanza di praticità col concetto di liberare le risorse alla chiusura di un applicativo derivata dall'utilizzo dei linguaggi managed a causa dell'utilizzo del gc che questi fanno porta a "cattive abitudini" quando si programma in questi linguaggi. Su questo non so cosa risponderti, non ho una risposta precisa: ancora, credo che riguardi più il tipo di insegnamento che si è ricevuto nella programmazione "in generale" che nella programmazione con linguaggi "managed" in particolare.

Originariamente inviato da tomminno

Ho avuto modo di fare esattamente gli stessi applicativi in più linguaggi e con un codice che è praticamente identico (tra l'altro assolutamente if-less), salvo le dovute differenze di linguaggio, la differenza prestazionale in questi casi era 1:8 e il bello è che essendo stato lo sviluppo C++ il porting di quello C# non mi ha portato via più di un paio d'ore, con il vantaggio che ora i parser riescono ad elaborare nelle 24 ore e a stare al passo con le tonnellate di log giornaliere.

Mi sembra di ricordare dei tuoi interventi sul forum in merito a questo problema: siccome però mi sembra molto strano, posso permettermi di pensare che tu abbia trovato un "caso particolare" in cui C++ funziona enormemente meglio di C#.

Originariamente inviato da tomminno

Infatti il C++ ormai è in disuso nelle aziende, relegato solo ad ambienti embedded, encoding audio/video; perchè ci sono aziende come Microsoft e Sun che hanno creato ambienti di sviluppo migliori.
A nessuno interessa la velocità di esecuzione.

Sei sicuro che costerebbe di più?

Magari triplica la cifra che hai menzionato.
Comunque ormai i linguaggi managed sono lo standard aziendale, perchè sono stati creati strumenti intorno che li rendono intrinsecamente migliori.

Che sono l'ambiente di sviluppo e gli strumenti immediatamente disponibili allo sviluppatore.

Anche perchè non hai alternative, le aziende oggi lavorano in Java o .NET.

Ne deduco che per te i linguaggi managed siano prevalenti per motivazioni storiche e non di merito: sono in sostanza capitati al momento giusto e nel posto giusto, e sono molto diffusi perchè tutti li usano e nessuno vuole gettarli via per far posto a qualcos'altro, visti i soldi investiti e la loro ubiquità. Poi ci sono ottime librerie, buoni ambienti di sviluppo eccetera.

Anche qui, non saprei cosa dirti: potrebbe anche essere vero (anche se qualcosa mi suggerisce che forse a nessuno interessava più gestire autonomamente certi problemi, e si è preferito delegarli per astrarre ulteriormente, e nel contesto tecnologico attuale il trade-off risulta sbilanciato verso i linguaggi managed). Però questo non è un buon motivo per programmare in un linguaggio come C++ anzichè in Java (o C#, o Ruby, o Python, ...).

Solo che a volte rimani scottato come con .NET 1.1 il cui ambiente di sviluppo non è più supportato in Vista e gli applicativi sono non importabili nei nuovi ambienti.

Non lo sapevo.

Credo che per funzionale tu intenda procedurale ovvero C (e non C++), altrimenti pensa che C# ha introdotto elementi di programmazione funzionale.

Lapsus.

[Mixmar]

Originariamente inviato da 71104

chi l'ha detto, i garbage collectors esistono anche per C++.

Non lo sapevo, ma in ogni caso, siccome tommino lamentava il fatto che i gc infliggono pesanti danni prestazionali alle applicazioni che ne fanno uso, mentre C++ ne è immune proprio perchè non li usa, non avrebbe molto senso paragonare C++ + gc con Java, perchè in teoria dovrebbero avere le stesse performance.

Io credo che però la JVM abbia altri "assi" nella manica per abbassare le performance in altre operazioni, tipicamente i controlli sugli array et similia, e che non sia il gc la vera causa del degrado prestazionale (che peraltro, sempre IMVHO, va cercato col lanternino, al di fuori degli ambiti in cui è sempre stato usato il C/C++ finora e nessuno ha mai pensato di cambiarlo con qualcos'altro).

Per tornare IT, penso che le probabilità di Johnn di incontrare questi ambiti sia molto bassa, e quindi gli suggerei di procedere con i linguaggi managed. Ecco.

Originariamente inviato da 71104

come mai adesso una libreria può essere utilizzata da programmi scritti in altri linguaggi solo se scritta in C o C++?

Intendevo dire: se proprio credi che la tua funzione / metodo / procedura fatta in Java / C # / ... sia troppo lenta perchè eseguita in JVM / CLR / ... , procurati o scriviti l'equivalente fatto in C / C++, testato, compilato, assemblato e "velocissimo", e invoca quello. In Java è complicato, in C# meno, eccetera.

Originariamente inviato da 71104

i drivers non sono librerie, spero sia chiaro...

Sì: ma sono scritti in C / C++ / Assembly e mi serviva un "esempio-di-codice-scritto-in-questi-linguaggi-che-riusi-senza-farti-troppi-problemi-per-motivi-di-performance-anche-se-non-sai-nulla-di-programmazione-unmanaged" (cioè, il mondo è pieno di codice unmanaged, e lo usiamo quando ci serve, senza bisogno di scrivere tutto in codice unmanaged).

[Johnn]

Originariamente inviato da tomminno

Ho avuto modo di fare esattamente gli stessi applicativi in più linguaggi e con un codice che è praticamente identico (tra l'altro assolutamente if-less), salvo le dovute differenze di linguaggio, la differenza prestazionale in questi casi era 1:8 e il bello è che essendo stato lo sviluppo C++ il porting di quello C# non mi ha portato via più di un paio d'ore, con il vantaggio che ora i parser riescono ad elaborare nelle 24 ore e a stare al passo con le tonnellate di log giornaliere.

Originariamente inviato da marco.r

Sono dell'opinione che piu' che che al linguaggio in se' la lentezza sia dovuta piu' a come e' architettata la libreria standard, con cataste di metodi ed oggetti. E' anche evidente che quando e' stata ideata le performance non erano tra i requisiti principali e la cosa si nota. Basta confrontare le classi di I/O di Java e C++ per notare la differenza. Questa tendenza tra l'altro mi sembra si sia diffusa anche agli utilizzatori, con i deleteri effetti del caso.

Ma perché l'I/O in Java (o C#) è più lento tanto da avere un rapporto di 1:8? E' l'uso errato di alcune classi di I/O non adatte allo scopo, errori di programmzione o carratteristiche intrinseche al linguaggio che non possono essere ovviate? Se è la libreria standard il problema, potrebbe essere modificata per migliorarla?

Originariamente inviato da incipit1970

Potresti usare smart pointers, ma anche quelli hanno un costo in termini di performance.

Originariamente inviato da Mixmar

Non lo sapevo, ma in ogni caso, siccome tommino lamentava il fatto che i gc infliggono pesanti danni prestazionali alle applicazioni che ne fanno uso, mentre C++ ne è immune proprio perchè non li usa, non avrebbe molto senso paragonare C++ + gc con Java, perchè in teoria dovrebbero avere le stesse performance.

Io credo che però la JVM abbia altri "assi" nella manica per abbassare le performance in altre operazioni, tipicamente i controlli sugli array et similia, e che non sia il gc la vera causa del degrado prestazionale (che peraltro, sempre IMVHO, va cercato col lanternino, al di fuori degli ambiti in cui è sempre stato usato il C/C++ finora e nessuno ha mai pensato di cambiarlo con qualcos'altro).

Proprio questo è un punto che mi incuriosisce parecchio. Esistono gc per c++, che però non sono stadard. Oppure si possono usare smart pointer. Ma in entrambi i casi si aggiunge overhead al velocissimo c++. Questo c++ + gc raggiunge o supera le "cattive" prestazioni del Java? Perché altrimenti o non si ha a che fare con problemi di deallocazione della memoria, o sono molto semplici essendo risolvibili con piccoli trucchi, oppure neanche si deve pensare al c++! In più, deallocazioni ad hoc affidate al programmatore, come possono essere, in generale più efficienti del garbage collector? Mi pare come il confronto tra C e assembler. L'assembler è sulla carta più efficiente, ma con i compilatori C odierni è quasi impossibile fare meglio.

Originariamente inviato da Mixmar

Per tornare IT, penso che le probabilità di Johnn di incontrare questi ambiti sia molto bassa, e quindi gli suggerei di procedere con i linguaggi managed. Ecco.

Il fatto è che sto valutando il porting di un software definito, quindi vorrei capire bene se le "inefficienze" di un linguagio unmanaged vengano bilanciate dai vantaggi. Il mio obiettivo sarebbe rendere l'implementazione java paragonabile a quella c++ (già esistente). Non potrei accettare un rapporto 1:8, ad esempio. Nel mio caso non avrò a che fare con db, risorse esterne e I/O. Solo ram e cpu.
Comunque la discussione che sta venendo fuori mi piace anche se vengono coinvolti aspetti come interfacce grafiche, db, ecc. in modo da capire quali sono i limiti di un linguaggio rispetto ad un altro e fare delle scelte opportune in futuro. Su queste tematiche mi pare i sia molta confusione e molto "sentito dire".

Per la discussione eclipse è lento/ no il mio è una scheggia, ho scoperto di recente che contanto anche le opzioni della jvm con cui viene lanciato.

Originariamente inviato da Mixmar

Intendevo dire: se proprio credi che la tua funzione / metodo / procedura fatta in Java / C # / ... sia troppo lenta perchè eseguita in JVM / CLR / ... , procurati o scriviti l'equivalente fatto in C / C++, testato, compilato, assemblato e "velocissimo", e invoca quello. In Java è complicato, in C# meno, eccetera.

Ma JNI è inefficiente/complicato? Solo a livello sintattico o c'è altro?

[tomminno]

Originariamente inviato da Mixmar

Sì, ma come hanno sottolineato altri, linguaggi managed e unmanaged condividono lo stesso insieme di problemi di "deallocazione" di risorse, solo che i linguaggi unmanaged ne aggiungono uno in più: quello della gestione della memoria (dello heap).

La differenza è che in C++ devo gestire solo la memoria nei linguaggi managed non gestisco la memoria ma tutto il resto.
Ad esempio se devo scrivere su un file in C++ una volta che l'oggetto di tipo ofstream è uscito dallo scope ho la garanzia che il file è chiuso, se uso lo StreamWriter in C# devo assicurarmi di usare lo using o gestire complicatamente a mano le possibili eccezioni per garantire la corretta chiusura del file (e dire che lavoro in una azienda dove è scosigliato l'utilizzo dello using "perchè fa casini", ma io sostanzialmente me ne frego delle indicazioni senza senso che arrivano dall'alto).
Non mi verrebbe mai in mente di mettere in C++ di mettere l'ofstream su heap.
Stesso discorso per le connessioni al db.

Forse però ti sto fraintendendo, e tu intendi dire che la mancanza di praticità col concetto di liberare le risorse alla chiusura di un applicativo derivata dall'utilizzo dei linguaggi managed a causa dell'utilizzo del gc che questi fanno porta a "cattive abitudini" quando si programma in questi linguaggi. Su questo non so cosa risponderti, non ho una risposta precisa: ancora, credo che riguardi più il tipo di insegnamento che si è ricevuto nella programmazione "in generale" che nella programmazione con linguaggi "managed" in particolare.

In buona sostanza si. Dato che c'è il GC ci possiamo pure permettere il lusso di non rilasciare le risorse o per lo meno di non sapere nemmeno che esiste l'interfaccia IDisposable e a cosa serva.

Mi sembra di ricordare dei tuoi interventi sul forum in merito a questo problema: siccome però mi sembra molto strano, posso permettermi di pensare che tu abbia trovato un "caso particolare" in cui C++ funziona enormemente meglio di C#.

I casi particolari sarebbero parecchi a quanto ho potuto sperimentare. Comunque è bello notare che anche usando un oggetto comune tra gli applicativi come il LogParser della Microsoft e quindi con un programma che effettua quasi esclusivamente chiamate all'oggetto COM e scrive su un file esegua in metà tempo se scritto in C++ rispetto a quello C#.
Per non parlare incredibilmente dell'accesso a file remoti, dove la lentezza della rete dovrebbe mitigare se non annullare le differenze.

Ne deduco che per te i linguaggi managed siano prevalenti per motivazioni storiche e non di merito: sono in sostanza capitati al momento giusto e nel posto giusto, e sono molto diffusi perchè tutti li usano e nessuno vuole gettarli via per far posto a qualcos'altro, visti i soldi investiti e la loro ubiquità. Poi ci sono ottime librerie, buoni ambienti di sviluppo eccetera.

No, secondo me hanno stravinto perchè ci sono state aziende che hanno sponsorizzato e quindi investito su linguaggi diciamo "proprietari" e quindi hanno creato strumenti e librerie per lo sviluppo migliori.
Lo standard C++ evolve ogni 10 anni con revisioni ogni 5 anni come tutti gli standard, non ha nessuna azienda che lo "sponsorizza" è chiaro che è rimasto indietro come linguaggio rispetto a quello che possono permettersi linguaggi aggiornati ogni 2 anni.
Cosa impedirebbe per dire di fare una libreria C++ che raccoglie il 95% delle caratteristiche del .NET? (rimane fuori la reflection)
Sarebbe così tremendamente più produttivo .NET?
Io dico di no per esperienza personale, ho avuto modo di partecipare a qualche grosso progetto in C++ dove c'era già tutto il codice necessario a smazzarsi le operazioni più noiose (che è quello che alla fine fa il framework .NET).

Anche qui, non saprei cosa dirti: potrebbe anche essere vero (anche se qualcosa mi suggerisce che forse a nessuno interessava più gestire autonomamente certi problemi, e si è preferito delegarli per astrarre ulteriormente, e nel contesto tecnologico attuale il trade-off risulta sbilanciato verso i linguaggi managed). Però questo non è un buon motivo per programmare in un linguaggio come C++ anzichè in Java (o C#, o Ruby, o Python, ...).

Ripeto ormai commercialmente il C++ è relegato ad ambienti molto ristretti quindi non è più un quesito da porsi.

[cdimauro]

Non bastano le librerie: anche il linguaggio fa la sua parte. E mi permetto di aggiungere: ovviamente.

Altrimenti non staremmo qui tutti a smazzarci C#, Java, Python, Ruby, ecc...

[tomminno]

Originariamente inviato da incipit1970

Non esattamente: la distruzione automatica degli oggetti C++ avviene unicamente per le variabili con scope in stack. Sul heap è come Java, ma senza GC. Se fai una new e dimentichi il delete, hai esattamente lo stesso problema (senza il GC che ti corregge la fuga di memoria, però).

Si ma assai probabilmente non avrei creato un oggetto nello heap.

Non per niente i programmi in C++ sono molto tendenti alle memory leaks, resource leaks e quant'altro (ci sono persino i debugger specializzati per scovare bug di quel tipo). Il GC è stato pensato appunto per correggere (in modo automatico e pertanto non ottimale) un comunissimo errore di programmazione (comune principalmente nei linguaggi unmanaged come C++). Potresti usare smart pointers, ma anche quelli hanno un costo in termini di performance.

Dalle mie escursioni con Reflector negli assembly .net credo che le prestazioni non siano degradate dal GC, ma dalle tonnellate di codice che stanno dietro ad ogni metodo esposto dal framework.

Certo dirai che una programmazione ideale dovrebbe prendere in considerazione questi errori, e concordo. Non è certo un diffetto del linguaggio, ma del programmatore. Ma questo è un mondo imperfetto: molti programmatori commettono questi errori, quindi eliminare la causa del problema migliora, in modo economico, la qualità del programma e diminuisce i cicli di correzione errori.

Poi, per quanto riguarda la velocità delle interfacce UI in Java, hai ragione, ma non vedo il problema: Java infatti è usato bene soprattutto in ambito enterprise, dove non ha paragoni per la richezza delle librerie e di codice già pronto. Non ha molto uso nella creazione di applicazioni client (nemmeno gli applet hanno avuto grosso successo, figuriamoci un programma in AWT). Se devo fare un programma che gira su Windows, userei Visual C++, o qualcosa di simile (non andrei nemmeno su C# o VisualBasic).

In ambito enteprise non hai nemmeno le interfacce grafiche, usi strumenti di ben altro livello per risolvere ben altri problemi (penso banalmente a ORM ed ESB), dove semplicemente l'ambiente .NET non arriva per limitazione, non a caso lo strumento Microsoft per l'ESB è in C++.
Tutto il resto è solo Java.

Di nuovo, ripeto: ogni linguaggio andrebbe usato nel ambito che più gli si addisce.

Infatti gli ambiti del C++ sono ridotti al lumicino.

[tomminno]

Originariamente inviato da cdimauro

Non bastano le librerie: anche il linguaggio fa la sua parte. E mi permetto di aggiungere: ovviamente.

Altrimenti non staremmo qui tutti a smazzarci C#, Java, Python, Ruby, ecc...

Il linguaggio senza la libreria standard che lo supporta è solo un'insieme di regole sintattiche e semantiche.
Il vantaggio enorme dei linguaggi managed è che generalmente i task di base sono già tutti fatti.
Se devo connettermi via TCP ho già la classe pronta, non devo ripartire dai socket BSD, se devo inviare una email ho la classe apposita, non devo implementarmi il protocollo SMTP, se devo connettermi ad un db ho pure lì la classe wrappata in modo che sia semplice da usare, non devo scrivermi io un wrapper sopra l'ODBC.
Prova però a dover fare da proxy tra un POP3 e SMTP e magicamente la produttività del linguaggio decade perchè non ci sono gli strumenti pre-creati.
Prova a lavorare su un ORM in C# e la produttività decade rispetto a Java dove ci sono strumenti integrati che smazzano il lavoro sporco.
Prova a creare un'applicazione enterprise in C# che gestisca lo scambio di messaggi e usi C++ o Java (e quindi scegli Java anche perchè offre prodotti open source).

[cdimauro]

Fortunatamente i linguaggi "managed" hanno ottime librerie.

Anche per C++ esistono, sia chiaro, ma non sono standard. E quando Boost diventerà parte dello standard, rimarrà comunque un framework gigantesco da portarsi dietro...

Comunque a parità di funzionalità di libreria, il linguaggio fa la differenza, eccome.

[incipit1970]

Originariamente inviato da Johnn

Ma perché l'I/O in Java (o C#) è più lento tanto da avere un rapporto di 1:8? E' l'uso errato di alcune classi di I/O non adatte allo scopo, errori di programmzione o carratteristiche intrinseche al linguaggio che non possono essere ovviate? Se è la libreria standard il problema, potrebbe essere modificata per migliorarla?

Lo è stata: infatti hanno implementato il NIO, che aggira alcuni dei colli di bottiglia del java.io tradizionale ed è molto più veloce (pochissimo di meno del I/O di C++).

Originariamente inviato da Johnn

Proprio questo è un punto che mi incuriosisce parecchio. Esistono gc per c++, che però non sono stadard. Oppure si possono usare smart pointer. Ma in entrambi i casi si aggiunge overhead al velocissimo c++. Questo c++ + gc raggiunge o supera le "cattive" prestazioni del Java? Perché altrimenti o non si ha a che fare con problemi di deallocazione della memoria, o sono molto semplici essendo risolvibili con piccoli trucchi, oppure neanche si deve pensare al c++! In più, deallocazioni ad hoc affidate al programmatore, come possono essere, in generale più efficienti del garbage collector? Mi pare come il confronto tra C e assembler. L'assembler è sulla carta più efficiente, ma con i compilatori C odierni è quasi impossibile fare meglio.

Si, esistono GC per C++. Come tutte le cose di C++ hanno il vantaggio della flessibilità, il GC non funziona per tutti gli oggetti in heap ma funziona come un bag dove metti ciò che vuoi (ti rimane dunque sempre il heap per utilizzare la memoria "in modo standard"). A velocità, come tutte le librerie, dipende dall'implementazione fatta.

Le deallocazioni "manuali" sono più efficienti (in media, non bisogna mai generalizzare) perché non devi controllare tutti gli oggetti allocati in un determinato momento per capire quali sono da riciclare e quali sono ancora in uso (questo è in pratica ciò che fa il GC). Dico in media perché in casi patologici di utilizzo di memoria al limite può verificarsi il contrario (un heap managed potrebbe anche avere un algoritmo di allocazione della memoria più efficiente di quello del SO sottostante, quindi tante chiamate a malloc() potrebbero far degenerare le performance).

Originariamente inviato da Johnn

Il fatto è che sto valutando il porting di un software definito, quindi vorrei capire bene se le "inefficienze" di un linguagio unmanaged vengano bilanciate dai vantaggi.

Il bilanciamento dipende dall'applicazione specifica. Come detto, in ambito enterprise i linguaggi managed superano di gran lunga l'utilità dei linguaggi unmanaged. Ma è una casistica particolare.

Originariamente inviato da Johnn

Il mio obiettivo sarebbe rendere l'implementazione java paragonabile a quella c++ (già esistente). Non potrei accettare un rapporto 1:8, ad esempio. Nel mio caso non avrò a che fare con db, risorse esterne e I/O. Solo ram e cpu.

Per quanto riguarda la RAM, come detto l'unico collo di bottiglia è il GC (e questo solo quando deve recuperare memoria perché si sta esaurendo). Se gestisci bene la memoria, il GC può funzionare poco, ed il degrado di prestazioni è molto contenuto. Per quanto riguarda la CPU, dipende da ciò che usi, in media le istruzioni di calcolo non sono molto diverse in termini di prestazioni rispetto a quelle di un linguaggio unmanaged, la maggior parte si traduce in chiamate al linguaggio macchina quasi senza intermediazione.

Un vantaggio di Java è che puoi fare un prototipo in poco tempo e fare qualche prova per vedere quanta differenza c'è. Implementa lo stesso algoritmo in entrambi i linguaggi e verifica i tempi di esecuzione su campioni di dati rappresentativi di ciò che dovrai andare ad implementare in seguito.

Originariamente inviato da Johnn

Comunque la discussione che sta venendo fuori mi piace anche se vengono coinvolti aspetti come interfacce grafiche, db, ecc. in modo da capire quali sono i limiti di un linguaggio rispetto ad un altro e fare delle scelte opportune in futuro. Su queste tematiche mi pare i sia molta confusione e molto "sentito dire".

In realtà, spesso si discute sul linguaggio, ma poco sul programmatore, che invece è chi veramente fa o disfa un programma. Anche se C/C++ è una scheggia, se implementi un algoritmo sballato o poco performante non risolvi niente avendo un linguaggio più "veloce". Una libreria con algoritmi efficienti basata su un linguaggio "lento" spesso risolve meglio di un linguaggio veloce con un algoritmo inefficiente. Un esempio un po' cretino ma valido: se usi un quicksort su Java, sarà sempre più veloce di un bubble sort implementato in C++.

Il vantaggio di avere tante librerie è dovuto al fatto che, in media, chi ha implementato la libreria ha studiato il problema e trovato gli algoritmi più efficienti, in C++ spesso devi fare di testa tua o non hai tempo per analizzare le alternative.

Molti dicono che un linguaggio è lento, ma non si sono minimamente disturbati ad usare un profiler per vedere dove stava il collo di bottiglia: 80 volte su 100, è negli algoritmi implementati da noi e non nel linguaggio vero e proprio.

Detto questo, io non sono contrario a C++ ed anzi lo uso volentieri, ma principalmente per applicazioni desktop (trovo non solo Java, ma qualsiasi altro linguaggio managed, uno spreco di risorse in questo tipo di applicazioni). Qualche volta, quando voglio usare in una applicazione desktop delle comode librerie Java, chiamo le classi Java direttamente dall'applicazione C++ (una specie di JNI a rovescio, è perfettamente fattibile).

Comunque, anche C++ ha delle librerie spettacolari (in media, la qualità del codice è molto superiore a quella delle librerie Java, che spesso non funzionano neanche o sono delle versioni alpha). Un paio di esempi: lo stesso Boost ed SQL Lite. Ma ce ne sono tantissime altre.

Originariamente inviato da Johnn

Ma JNI è inefficiente/complicato? Solo a livello sintattico o c'è altro?

Inefficiente non è (stai chiamando un metodo scritto in C/C++, quindi la velocità di esecuzione è quella del normale C/C++). Complicato forse un po', ma soprattutto sul lato C++, non tanto sul lato Java. Ma almeno a me è bastato vedere un paio di esempi per riuscire ad usarlo senza problemi di sorta.

[cdimauro]

Originariamente inviato da incipit1970

Le deallocazioni "manuali" sono più efficienti (in media, non bisogna mai generalizzare) perché non devi controllare tutti gli oggetti allocati in un determinato momento per capire quali sono da riciclare e quali sono ancora in uso (questo è in pratica ciò che fa il GC). Dico in media perché in casi patologici di utilizzo di memoria al limite può verificarsi il contrario (un heap managed potrebbe anche avere un algoritmo di allocazione della memoria più efficiente di quello del SO sottostante, quindi tante chiamate a malloc() potrebbero far degenerare le performance).

In genere i linguaggi non chiamano sempre malloc e free per ogni allocazione, ma fanno uso di pool di memoria, ed è questo che, quando serve, le richiama.

Comunque le deallocazioni "manuali" (o immediate) non sempre più efficienti. Spesso è meglio lasciar allocato lo spazio e liberarlo do un po', quando serve memoria, perché tendenzialmente diminiuisce la frammentazione della memoria (ed è poi più facile compattare i blocchi di memoria).

Per quanto riguarda la RAM, come detto l'unico collo di bottiglia è il GC (e questo solo quando deve recuperare memoria perché si sta esaurendo). Se gestisci bene la memoria, il GC può funzionare poco, ed il degrado di prestazioni è molto contenuto. Per quanto riguarda la CPU, dipende da ciò che usi, in media le istruzioni di calcolo non sono molto diverse in termini di prestazioni rispetto a quelle di un linguaggio unmanaged, la maggior parte si traduce in chiamate al linguaggio macchina quasi senza intermediazione.

Ci sono linguaggi e/o implementazioni che permettono di controllare il funzionamento del GC.

Un vantaggio di Java è che puoi fare un prototipo in poco tempo e fare qualche prova per vedere quanta differenza c'è. Implementa lo stesso algoritmo in entrambi i linguaggi e verifica i tempi di esecuzione su campioni di dati rappresentativi di ciò che dovrai andare ad implementare in seguito.

Infatti uno dei punti chiave dello sviluppo agile è di avere il prima possibile un prototipo per testare il comportamento dell'applicazione con dai reali.

Detto questo, io non sono contrario a C++ ed anzi lo uso volentieri, ma principalmente per applicazioni desktop (trovo non solo Java, ma qualsiasi altro linguaggio managed, uno spreco di risorse in questo tipo di applicazioni). Qualche volta, quando voglio usare in una applicazione desktop delle comode librerie Java, chiamo le classi Java direttamente dall'applicazione C++ (una specie di JNI a rovescio, è perfettamente fattibile).

Mah. Io la penso in maniera diametralmente opposta: è con applicazioni desktop che sarebbe preferibile l'uso di linguaggi managed, perché non sono importanti le prestazioni quanto il funzionamento del programma e la velocità con la quale lo si sviluppa.

Poi è anche vero che tutti i server che ho sviluppato finora li ho scritti in Python...

Comunque, anche C++ ha delle librerie spettacolari (in media, la qualità del codice è molto superiore a quella delle librerie Java, che spesso non funzionano neanche o sono delle versioni alpha). Un paio di esempi: lo stesso Boost ed SQL Lite. Ma ce ne sono tantissime altre.

Boost però è un pachiderma.

SQLite è carino (e ci sono binding per praticamente qualunque linguaggio), ma è fortemente fuori specifiche SQL e implementa veramente pochi costrutti. Insomma, per uno che è abituato a trigger, procedure, ecc. è quanto di meno desiderabile. Ma nel suo piccolo ha anche la sua utilità.

[Vincenzo1968]

Originariamente inviato da incipit1970

...
Comunque, anche C++ ha delle librerie spettacolari (in media, la qualità del codice è molto superiore a quella delle librerie Java, che spesso non funzionano neanche o sono delle versioni alpha). Un paio di esempi: lo stesso Boost ed SQL Lite. Ma ce ne sono tantissime altre.
...

Ohé, non babbiamo: SQLite è scritto in C

Originariamente inviato da cdimauro

...
SQLite è carino (e ci sono binding per praticamente qualunque linguaggio), ma è fortemente fuori specifiche SQL e implementa veramente pochi costrutti. Insomma, per uno che è abituato a trigger, procedure, ecc. è quanto di meno desiderabile. Ma nel suo piccolo ha anche la sua utilità.

L'obiettivo dei progettisti non era, e non è, la sostituzione di SQL Server o Oracle:

http://www.sqlite.org/whentouse.html

SQLite is not designed to replace Oracle. It is designed to replace fopen().

[cdimauro]

Non farà concorrenza a Oracle, ma implementa più di una semplice fopen, ecc.: http://www.sqlite.org/lang.html e http://www.sqlite.org/omitted.html

Sicuramente in futuro miglioreranno i trigger, e magari introdurranno le stored procedure: sono caratteristiche troppo utili per non inserirle.

Comunque se devo utilizzare un db embedded preferisco questo, che è MOOOLTO più completo (e passare poi da embedded a client/server è una bazzecola).

[Vincenzo1968]

Originariamente inviato da cdimauro

Non farà concorrenza a Oracle, ma implementa più di una semplice fopen, ecc.: http://www.sqlite.org/lang.html e http://www.sqlite.org/omitted.html

Sicuramente in futuro miglioreranno i trigger, e magari introdurranno le stored procedure: sono caratteristiche troppo utili per non inserirle.

Comunque se devo utilizzare un db embedded preferisco questo, che è MOOOLTO più completo (e passare poi da embedded a client/server è una bazzecola).

Sono tutt'e due molto efficienti(utilizzano entrambi parser di tipo LALR(1) per il parsing SQL ).
SQLite, se non si hanno troppe pretese(Multiutenza, triggers, etc), mi sembra la soluzione migliore. È più leggero e più facile da utilizzare.

[cdimauro]

Originariamente inviato da Vincenzo1968

Sono tutt'e due molto efficienti(utilizzano entrambi parser di tipo LALR(1) per il parsing SQL ).

Di questo lo sai che me ne frego.

SQLite, se non si hanno troppe pretese(Multiutenza, triggers, etc), mi sembra la soluzione migliore. È più leggero e più facile da utilizzare.

Più facile da usare per la mia esperienza no. Sarà perché conosco bene FireBird, ma lavoro molto meglio e molto più velocemente con quest'ultimo (specialmente con trigger e stored procedure).

Più leggero SQLite lo è sicuramente: FireBird occupa 10 volte di più come spazio. Ma oggi chi se ne frega di passare da 400K a 4MB di memoria occupata? Io preferisco che FireBird usi 4MB, ma mi metta a disposizione quegli utilissimi strumenti che mi semplificano la vita.

[Johnn]

Originariamente inviato da Johnn

Un oggetto Java "spreca" della memoria oltre ai dati dichiarati dal programmatore?
Grazie!

Ma riguardo ciò, cosa mi sapete dire?