[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?