JAVA più lento del C++. Ma quanto?

[cionci]

Originariamente inviato da dupa

si ma scusa se tu usi le librerie Win32 stai usando cose che occupano "memoria" e allo stesso modo la JVM occupa memoria.. quindi non ho capito perchè se la memoria la occupa la JVM non va bene.. se la occupano le librerie Win32 va bene.. mah.

Perché se usi la JVM usi sia le dll Win32 che la JVM...mentre su un programma Win32 usi solo le dll Win32 Tanto le dll di Win32 le devi comunque usare...qualsiasi cosa tu faccia su Windows...stessa cosa per le system call di Linux

[cdimauro]

Originariamente inviato da marco.r

Azureus e' la dimostrazione che spesso il tempo risparmiato grazie all'uso di linguaggi piu' fruibili andrebbe dedicato a bersi un paio di birre in piu' e non a scrivere altro codice

Originariamente inviato da marco.r

Verissimo. Diciamo che pero' e' l'esempio (uno dei tanti) di una propensione all'over-engineering secondo me piu' diffusa tra i programmatori Java che non tra altri, e che contribuisce alla nomea di lentezza del linguaggio.

Due post da incorniciare...

P.S. Ma qui ci vorrebbe Cyrano...

[shinya]

Originariamente inviato da dupa

mi ritengo un buon programmatore, ai tempi dell'università l'esame di fondamenti d'informatica 1, al secondo compitino c'erano 3 esercizi abbastanza complessi in C++ e fui l'unico a farli tutti e 3 giusti nel tempo che ci era stato dato (era abb. breve)...

HAHA! Scusa, ma questa mi fa ridere...posso usarla come sign?

[dupa]

Originariamente inviato da shinya

HAHA! Scusa, ma questa mi fa ridere...posso usarla come sign?

boh, se ti fa ridere...

[banryu79]

Originariamente inviato da fek

...
Qui si fatica a percepire il fatto che la risorsa piu' scarsa non e' la memoria o la cpu, ma il tempo dei programmatori.
...

Quoto al 100%.
Questa è la risorsa più importante, da tutti i punti di vista.

OT: bel 3D, meriterebbe uno sticky

[banryu79]

... ovvero un esempio tratto dal mondo reale che dimostra come, in talune situazioni pratiche, Java venga scelto anche per via delle sue performance.

L'articolo risale al 2005, quindi è un po' datato ma molto interessante, tratta infatti di un sistema di telemetria per Formula 1 realizzato basandosi su tecnologia Jini.

qui c'è l'articolo

In particolare vorrei porre l'attenzione su questo passaggio

Ci piace subito sottolineare, a riprova di quanti passi avanti abbia compiuto Java in questi dieci anni, che uno dei problemi che non abbiamo avuto è stato quello della performance. In particolare, sul requisito della latenza siamo riusciti, senza troppi problemi, a garantire tempi non superiori a 10ms, molto al di sotto dei requisiti richiesti (per completezza sarebbe necessario dare qualche riferimento alla classe di hardware utilizzato: in sommi capi, perché varia da scuderia a scuderia, i client sono laptop di fascia altra e i server tipicamente sono macchine biprocessore di fascia medio-bassa. Insomma, niente di fantascientifico). Chissà se in futuro finirà finalmente la leggenda urbana che dice che “Java è lento”?

[cionci]

Originariamente inviato da banryu79

Java venga scelto anche per via delle sue performance.

Scusa, ma anche nel passo che riporti non si parla di performance, ma di quanto le performance non siano state un problema per l'applicazione in questione.

[banryu79]

Sì hai ragione, infatti ho detto che è un po' OT rispetto al discorso "Java più lento di C++"...

E' che poi il 3d ha spaziato rispetto al tema specifico del titolo; il fatto è che alla luce di tutti gli altri aspetti complementari che ruotano intorno alla realizzazione di un software, l'aspetto singolo "Java più lento di C++" può depistare un attimo chi si pone il problema di quale linguaggio utilizzare per, ad esempio, sistemi real time.

L'articolo postato la dice lunga proprio su questo aspetto (e altri, non strettamente legati alle performance ma ad altre problematiche).

Detto questo mi tolgo di torno: è chiaro che qui sono andato un po' troppo OT però aprire un nuovo 3d mi sembrava troppo

Ciao

[cionci]

Nono...ci stava benissimo con il thread...fa vedere che quando i requisiti di tempo non sono strettissimi le performance non sono un problema.

[fek]

Originariamente inviato da cionci

Scusa, ma anche nel passo che riporti non si parla di performance, ma di quanto le performance non siano state un problema per l'applicazione in questione.

Il passo interessante secondo me riguarda la garanzia di latenza che riescono a dare al di sotto dei 10ms. E' interessante perche' di solito quando c'e' un garbage collector di mezzo non si e' mai garantiti sulle latenze: per questo in sistemi strettamente real-time e' preferibile usare C++ non per le performance ma per le garanzie sulla latenza. E' anche il motivo per il quale gli engine 3d si scrivono in C++, perche' sono sistemi real-time!

Altra curiosita', in 10ms devo disegnare un terzo della scena, non pensate che siano pochi.

[banryu79]

Originariamente inviato da cionci

Nono...ci stava benissimo con il thread...fa vedere che quando i requisiti di tempo non sono strettissimi le performance non sono un problema.

Come fai a dire che "i requisiti di tempo non sono strettissimi" in riferimento al caso di cui si parla nell'articolo? Dubito che tu sia già riuscito a leggerlo tutto è un po' lunghetto.

Comunque, a tal proprosito, proprio nella conclusione dell'articolo:

Conclusioni
Dobbiamo dire subito una cosa: il progetto è stato stressante, ma ci siamo divertiti: non capita molto spesso di poter utilizzare una tecnologia di frontiera, come Jini e Rio, in un ambito così delicato e challenging come la Formula Uno. È stata una grande soddisfazione portare a termine la realizzazione di un progetto così difficile (oltretutto in pochi mesi e con un sostanziale rispetto dei tempi) in un'area dove in molti non avrebbero scommesso a priori l'effettiva usabilità di Java.

Ciao

[banryu79]

Originariamente inviato da fek

Il passo interessante secondo me riguarda la garanzia di latenza che riescono a dare al di sotto dei 10ms.

Infatti, nelle specifiche si progetto, secondo quanto riportato nell'articolo, si richiedeva di rispettare una latenza massima di 50 ms.

Loro sono riusciti a stare entro i 10 ms: secondo me uno scarto così grande rispetto la richiesta significa che cmq per ottenere i 10 ms. non hanno dovuto fare i "salti mortali" (se così fosse stato, vista la complessità globale del progetto e i tempi stretti, credo avrebbero sforato, imho)

[cionci]

Ho letto un po'...non tutto. Ma i 10ms è il tempo in cui sono riusciti a mantenere la latenza...
In particolare, sul requisito della latenza siamo riusciti, senza troppi problemi, a garantire tempi non superiori a 10ms, molto al di sotto dei requisiti richiesti
La latenza richiesta era almeno 5 volte più alta, quindi non sono requisiti di tempo strettissimi E non è un'applicazione real-time.

[banryu79]

Originariamente inviato da cionci

La latenza richiesta era almeno 5 volte più alta, quindi non sono requisiti di tempo strettissimi E non è un'applicazione real-time.

Vero, chiedo venia


Ma che mi dici di questo?

Vabbè dai, in questo 3d io faccio il crociato per Java

[marco.r]

Originariamente inviato da fek

Altra curiosita', in 10ms devo disegnare un terzo della scena, non pensate che siano pochi.

Immagino ! Domanda correlata: anche in C++ allocazioni e deallocazioni hanno un loro costo, anche se piu' controllabile, e penso soprattutto al caso di strutture dati composte da diversi oggetti diversi piu' piccoli. Nel vostro campo questo crea problemi ? Se si', quali sono gli accorgimenti tipici che adottate ?

[fek]

Originariamente inviato da marco.r

Immagino ! Domanda correlata: anche in C++ allocazioni e deallocazioni hanno un loro costo, anche se piu' controllabile, e penso soprattutto al caso di strutture dati composte da diversi oggetti diversi piu' piccoli. Nel vostro campo questo crea problemi ? Se si', quali sono gli accorgimenti tipici che adottate ?

In C++ allocazione/disallocazione sono operazioni considerate "lente". Poi gli accorgimenti dipendono da caso a caso: all'interno del render loop, di solito, non si alloca MAI. Il problema qui non e' tanto il tempo che si perde nelle operazioni di allocazioni/disallocazione, ma la frammentazione dell'heap: dopo qualche ora di gioco non vuoi che il render loop si inchiodi perche' un'allocazione fallisce a causa della troppa frammentazione...

Le soluzioni sono varie: al momento usiamo spesso allocatori custom. Ad esempio, se devi allocare della memoria che sai che vive solo per un flame, lo allochi con un semplice veloce allocatare che si limita ad un'addizione in uno spazio di memoria preallocato e alla fine del frame pulisce tutto.
Oppure uso un allocatoare a stack per la memoria video: alloco oggetti (render target) e disallocco in ordine inverso. E' veloce e mi garantisce nessuna frammentazione.

Poi dipende da caso a caso. Se vuoi, uno dei veri vantaggi del C++ rispetto a Java/C# e' l'avere questo livello di controllo sulle policy di allocazione e sulla gestione della memoria, cosa che non e' possibile in un linguaggio ad alto livello. Ed e' anche vero che questo livello di controllo porta tutta una serie di problemi non trascurabili.

[Angus]

Originariamente inviato da tomminno

Infatti Java è proliferato in tutti altri ambiti, non è mai diventato il linguaggio dei tostapane come pensato originariamente.

hmmm... MHP

[marco.r]

Originariamente inviato da fek

In C++ allocazione/disallocazione sono operazioni considerate "lente". Poi gli accorgimenti dipendono da caso a caso: all'interno del render loop, di solito, non si alloca MAI. Il problema qui non e' tanto il tempo che si perde nelle operazioni di allocazioni/disallocazione, ma la frammentazione dell'heap: dopo qualche ora di gioco non vuoi che il render loop si inchiodi perche' un'allocazione fallisce a causa della troppa frammentazione...

Non mi ero spiegato molto bene . Fin qui c'ero gia', perche' e' bene o male la situazione che abbiamo noi in laboratorio (il ciclo di controllo dei nostri robot va circa a 5 kHz e di conseguenza le allocazioni nel suo interno sono assolutamente vietate). Nel nostro caso pero' la situazione e' facilmente gestibile in quanto all'interno del loop bene le operazioni da eseguire sono abbastanza regolari (o anche assistite da hw esterno come fpga), e riusciamo tranquillamente a spostare su thread/processi esterni le operazioni che coinvolgono la memoria. Mi incuriosiva proprio la questione della gestione quando questo non si puo' fare.

Le soluzioni sono varie: al momento usiamo spesso allocatori custom. Ad esempio, se devi allocare della memoria che sai che vive solo per un flame, lo allochi con un semplice veloce allocatare che si limita ad un'addizione in uno spazio di memoria preallocato e alla fine del frame pulisce tutto.
Oppure uso un allocatoare a stack per la memoria video: alloco oggetti (render target) e disallocco in ordine inverso. E' veloce e mi garantisce nessuna frammentazione.

Grazie mille della risposta. Proprio quello che volevo sapere.

Poi dipende da caso a caso. Se vuoi, uno dei veri vantaggi del C++ rispetto a Java/C# e' l'avere questo livello di controllo sulle policy di allocazione e sulla gestione della memoria, cosa che non e' possibile in un linguaggio ad alto livello. Ed e' anche vero che questo livello di controllo porta tutta una serie di problemi non trascurabili.

Avevo letto un po' di tempo fa di estensioni di Java in cui si demarcavano con appositi attributi metodi/istanze/etc. in modo da marcare in modo esplicito i margini di vita degli oggetti ed ottenere, ad esempio allocazione assicurata sullo stack piuttosto che garanzie sui tempi di esecuzione etc. ma, al di la' dell'appesantimento del linguaggio, si trattava come spesso accade di estensioni chiuse (seppure prodotte dalla stessa Sun) e di un costo non banale.

[Mixmar]

Originariamente inviato da marco.r

Non mi ero spiegato molto bene . Fin qui c'ero gia', perche' e' bene o male la situazione che abbiamo noi in laboratorio (il ciclo di controllo dei nostri robot va circa a 5 kHz e di conseguenza le allocazioni nel suo interno sono assolutamente vietate). Nel nostro caso pero' la situazione e' facilmente gestibile in quanto all'interno del loop bene le operazioni da eseguire sono abbastanza regolari (o anche assistite da hw esterno come fpga), e riusciamo tranquillamente a spostare su thread/processi esterni le operazioni che coinvolgono la memoria. Mi incuriosiva proprio la questione della gestione quando questo non si puo' fare.

Piccolo OT: anche se ho (quasi) sempre programmato con linguaggi managed e non ho mai avuto l'onere/l'onore di confrontarmi direttamente con problemi di gestione della memoria, rimango sempre affascinato da queste argomentazioni... mi sembra quasi di riuscire a capire i dettagli! (Ma questo dipenderà dalla competenza di chi li espone... ).

Originariamente inviato da marco.r

Avevo letto un po' di tempo fa di estensioni di Java in cui si demarcavano con appositi attributi metodi/istanze/etc. in modo da marcare in modo esplicito i margini di vita degli oggetti ed ottenere, ad esempio allocazione assicurata sullo stack piuttosto che garanzie sui tempi di esecuzione etc. ma, al di la' dell'appesantimento del linguaggio, si trattava come spesso accade di estensioni chiuse (seppure prodotte dalla stessa Sun) e di un costo non banale.

Forse l'approccio migliore sarebbe qualcosa di simile al costrutto "unsafe" del C#: il problema è che di fatto più che una feature del linguaggio, in quel caso è una feature della CLR, e poi rompe il "contratto" dell'utilizzo di un linguaggio managed... senza considerare il fatto che non ho idea delle condizioni della memoria che si trovi di fronte chi usi un pezzo di programma in modo managed, poi entri in "unsafe mode", senza avere idea di quello che la CLR ha fatto per lui e dello stato della memoria che si trova davanti.

Almeno con un linguaggio "compilato" si può determinare (più o meno) lo stato della memoria perchè se ne gestisce personalmente l'evoluzione, ma in questo caso "ibrido" non so proprio cosa possa succedere... qualcuno ha esperienze in proposito?

[marco.r]

Originariamente inviato da Mixmar

Forse l'approccio migliore sarebbe qualcosa di simile al costrutto "unsafe" del C#: il problema è che di fatto più che una feature del linguaggio, in quel caso è una feature della CLR, e poi rompe il "contratto" dell'utilizzo di un linguaggio managed... senza considerare il fatto che non ho idea delle condizioni della memoria che si trovi di fronte chi usi un pezzo di programma in modo managed, poi entri in "unsafe mode", senza avere idea di quello che la CLR ha fatto per lui e dello stato della memoria che si trova davanti.

Quel che riportavo nel passaggio qui sopra e' in un certo senso il contrario: il programmatore istruisce il compilatore delle condizioni che il codice deve soddisfare, e questo segnala errore se non riesce a verificarle. Ad esempio se voglio avere la garanzia che in un determinato loop non ci siano allocazioni (sullo heap), posso marcare in modo opportuno tutti i metodi che devo chiamare. Il compilatore verifichera' che tutti gli oggetti creati in quelle chiamate non possano "scappare" fuori, e che il loro ciclo di vita si concluda all'interno del loop. Se e' cosi', potra' allocare gli oggetti direttamente sullo stack, ottenendo idealmente l'effetto degli allocatori custom di cui parlava fek prima.
Questo in linea di principio, ci sono delle differenze e le cose sono un po' piu' complicate di cosi', ma penso possa rendere l'idea. Purtroppo non riesco a trovare il link che ne parlava...