Java o c [Archivio] - Hardware Upgrade Forum

View Full Version : Java o c

feboss

15-10-2006, 03:26

telepuglia

15-10-2006, 12:18

Mi sono iscritto questo anno all'universita, facoltà di scienze informatiche.
e da quando è iniziato il corso ho un dubbio che mi martella la testa...
Ma perchè studio java quando il 90% dei programmi è fatto in c/c++?
Perchè ovunque, in internet, leggo che il linguaggio "migliore" è java quando tutto il mondo opensource ruota su c/c++?

Non mi risulta che emule e tantissimi altri programmi sono scritti in java.Anzi...
Il 99% dei programmi in linux sono scritti in c++...
PERCHE JAVA ALLORA?

Ciao, rispondo alle domande sollevate...

1. Il 90% dei programmi consumer è in c/c++ ma le piattaforme di servizi delle principali aziende NON sono in c/c++ (pensa all'home banking, al dvb, ecc...).

2. Java non è il linguaggio migliore ma semplicemente perchè non esiste!
Migliore rispetto a quali parametri?

3. Non puoi avere come riferimento il mulo...conosci eclipse? E' solo UN esempio di programma scritto in java. E non è vero che TUTTO il mondo open source ruota sul c, eclipse è open source!

Credo sia corretto studiare Java per alcuni motivi (sono solo alcuni) :

1. E' un linguaggio OOP.

2. E' ampiamente diffuso.

3. E' lo standard di riferimento di molti prodotti commerciali e open source.

4. Ampio supporto alla programmazione distribuita, SOA, web services...

Quindi il consiglio è: studia sia il c/c++ che Java! ma anche python, .net, pl/sql...

feboss

15-10-2006, 12:56

franksisca

15-10-2006, 13:06

La risposta che mi ha dato il prof all'uni è stata:
La maggior parte dei programmi in linux è scritta in c perchè i programmatori sono persone che sono mature e ai loro tempi non esisteva ancora il java -.-
vero, infatti il java è del 95.......solo adesso si stanno facendo programmi seri sul java perchè solo adesso si è maturati sotto questo aspetto;)

telepuglia

15-10-2006, 13:14

Scoperchiatore

15-10-2006, 13:37

Allora perchè linux è scritto interamente in c/c++, e non in java?
A questo punto sarebbe piu comodo sviluppare il software in java, lo usi su linux, mac e windows allo stesso tempo.
Bho io continuo a non capire

La risposta che mi ha dato il prof all'uni è stata:
La maggior parte dei programmi in linux è scritta in c perchè i programmatori sono persone che sono mature e ai loro tempi non esisteva ancora il java -.-

Spero che il prof voglia nascondere volutamente tanti dettagli in questo discorso.

Le performance sono disastrose in Java.
Java si basa su un qualcosa, la JVM, che non si può supporre sempre di avere.
La JVM ha tanti bugs, e fino alla versione 1.4 la sua evoluzione era diciamo "sconsiderata"
In Java le librerie grafiche hanno raggiunto solo negli ultimi anni livelli umani di usabilità e gradevolezza estetica.
Java è lento
Java è lento
Java è lento

Diciamo che i motivi sono più o meno questi.
Mettici che programmare imperativo ha un grado di difficoltà in meno del programmare a oggetti, e che per un progetto piccolo scritto da 4 persone, difficilmente si fanno Use Cases o analisi di complessità. E quindi il gioco Java non vale la candela.

Java è fondamentale in alcuni contesti, in cui C o C++ ti aiutano veramente poco. Penso ai servizi Web, alle applicazioni distribuite, all'integrazione fra macchine con diversi sitemi operativi, e via dicendo.

Java non lo puoi usare quando le prestazioni sono fondamentali. A quel punto ti devi ingegnare con C o C++, perchè con Java ti potresti trovare davanti al programma più ottimizzato del mondo, ed avere ancora tempi di risposta indecenti.

Avrai tempo di imparare perchè Java non è utile.
Ma condiera anche che, se sai programmare in Java, imparare C è poca cosa, imparare C++ è pochissima cosa. L'esperienza, poi, è un altro conto...

kalebbo

15-10-2006, 13:46

telepuglia

15-10-2006, 14:15

Java è lento
Java è lento
Java è lento

Falso, Java non è così lento! Forse ti riferisci alla 1.1 :)

Ovvio pagare in fase di startup una maggiore lentezza, ma molto dipende anche dal programmatore...basta saper scrivere del codice che "in un qualche modo" porta a dei risulati per definirsi guru del linguaggio! Non è così! C'è ancora chi fa uso esteso della classe thread-safe Vector!

Per non parlare dei JIT!

Basta dare un'occhiata ai benchmark...

PGI-Bis

15-10-2006, 14:31

Spero che il prof voglia nascondere volutamente tanti dettagli in questo discorso.

Le performance sono disastrose in Java.
Java si basa su un qualcosa, la JVM, che non si può supporre sempre di avere.
La JVM ha tanti bugs, e fino alla versione 1.4 la sua evoluzione era diciamo "sconsiderata"
In Java le librerie grafiche hanno raggiunto solo negli ultimi anni livelli umani di usabilità e gradevolezza estetica.
Java è lento
Java è lento
Java è lento

Diciamo che i motivi sono più o meno questi.
Mettici che programmare imperativo ha un grado di difficoltà in meno del programmare a oggetti, e che per un progetto piccolo scritto da 4 persone, difficilmente si fanno Use Cases o analisi di complessità. E quindi il gioco Java non vale la candela.

Java è fondamentale in alcuni contesti, in cui C o C++ ti aiutano veramente poco. Penso ai servizi Web, alle applicazioni distribuite, all'integrazione fra macchine con diversi sitemi operativi, e via dicendo.

Java non lo puoi usare quando le prestazioni sono fondamentali. A quel punto ti devi ingegnare con C o C++, perchè con Java ti potresti trovare davanti al programma più ottimizzato del mondo, ed avere ancora tempi di risposta indecenti.

Avrai tempo di imparare perchè Java non è utile.
Ma condiera anche che, se sai programmare in Java, imparare C è poca cosa, imparare C++ è pochissima cosa. L'esperienza, poi, è un altro conto...

Una collezione di corbellerie di questa portata merita un :eek:

Scoperchiatore

15-10-2006, 15:20

Una collezione di corbellerie di questa portata merita un :eek:

Ed una risposta come questa merita un :D

Cmq, fammele notare queste corbellerie, dato che sono condivise da molti.

Io ho programmato in Java per 5 anni convinto che fosse uno dei migliori linguaggi del mondo. Dicevo anche io che la "lentezza" era limitata. Poi mi sono trovato davanti a problemi diversi, più complessi del solito DB distribuito o del sitarello in JSP, e ho capito come l'indirezione della JVM peggiori in modo estremo le prestazioni di alcuni software in alcuni campi.

E' vero sicuramente che un programmatore deve ottimizzare a vari livelli, ma alcune volte ottimizzare è impossibile. Talvolta, si devono memorizzare una tal mole di informazioni che la sola memoria per contenerle tutte, SENZA STRUTTURAZIONE, è maggiore di quella del server a cui viene tolta quella della JVM e dei programmi esterni
Altre volte, sei davanti ad un algoritmo con complessità lineare (sappiamo cosa vuol dire, vero? altrimenti è inutile parlare) ma la mole di dati in ingresso è talmente alta che, nonostante tu abbia la complessità migliore possibile, le operazioni a costo "unitario" sono talmente tante da impedire la realizzazione del lavoro stesso.

Io non ho detto che Java fa schifo e che non va mai usato. Ho detto solo che ci ho sbattuto seriamente la testa davanti alla differenza di prestazioni di uno stesso algoritmo in Java ed in C, e mi sono accorto che in questi casi il rapporto è realmente di 1:10, come descritto da qualche accanito sostenitore di C.

La cosa mi spiace, perchè C ha talmente tanti limiti come strutturazione, documentazione, ereditarietà e polimorfismo, che realizzare un programma in C equivale spesso a creare un artefatto difficilmente comprensibile e manutenibile.

Eppure Java ha delle limitazioni oggettive che non possono essere dimenticate, e che vanno tenute in conto in molti contesti.

In altri contesti, Java va benissimo, come sottolineato.

Scoperchiatore

15-10-2006, 15:41

Falso, Java non è così lento! Forse ti riferisci alla 1.1 :)

Ovvio pagare in fase di startup una maggiore lentezza, ma molto dipende anche dal programmatore...basta saper scrivere del codice che "in un qualche modo" porta a dei risulati per definirsi guru del linguaggio! Non è così! C'è ancora chi fa uso esteso della classe thread-safe Vector!

Per non parlare dei JIT!

Basta dare un'occhiata ai benchmark...

Le lauree oggi come oggi non valgono un cazzo, ok, ma io cell'ho :D
Non sarò un guru, ma qualche esperienza l'ho accumulata ;)

Cosa discrimina l'utilzzatore di Vector da quello che usa BlockingQueue? :mbe:

Capito da solo: hai letto anche tu qua:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
:D

Anche questo articolo, molto a favore di Java, sottolinea che Java oggi come oggi ha fatto passi da gigante, ma può essere ancora reso lento, se si vuole.

Inoltre, l'articolo non cita che esistono Gargage Collector anche per C/C++, che in C è possibile ottimizzare l'allocazione di memoria manualmente sovrascrivendo la malloc (che è spesso un passo seguito dall'installazione di una gargage collector) e via dicendo ;)

Qui, invece, il tizio dice che Java si è comportato bene, e che rispetto alla versione 1.0.2 si sono fatti passi da gigante:
http://mathsrv.ku-eichstaett.de/MGF/homes/grothmann/java/bench/Bench.html
ma se poi vedi i benchmark, abbiamo il 15% di lentezza in più, in media.

Considera il mio caso: algoritmo di complessità lineare, che deve aprire un file di testo da almeno 10 Gb, se non di più. L'elaborazione deve essere completata entro 18 ore, che è il resto del tempo disponibile in un giorno, tolto quello dedito allo scaricamento.

Il tempo non è un problema: il problema è la memoria (2.6 GB occupati nella versione ottimizzata). Ti pare che con questi presupposti potevo affidarmi a Java? Per un calcolo parallelo su matrici, la JVM allocata con 512 Mb di Ram è morta a una matrice 10.000x10.000 = 10 miliardi di elementi.
Io devo leggerne un numero comparabile, solo che invece di essere numeri, sono informazioni strutturate e anche spesso ridondanti (per mantenere l'elaborazione lineare rispetto al numero di record in input).

In questo contesto, l'indirezione della JVM mi pesa, il non poter controllare personalmente l'allocazione della memoria mi pesa, anche solo 1 byte di overhead per memorizzare "Integer" mi pesa da morire. E quindi Java va scartato a priori.

Il discorso non è così "di nicchia" se ci pensate bene. Servizi che si occupano dell'incrocio di informazioni enormi derivati da piccole osservazioni locali, di processamento di volumi di dati provenienti da fonti differenti sono molto comuni oggi. E sinceramente io non investirei tempo nel provare un'implenentazione Java di queste cose se non si è certi che si possa garantire il servizio

Inoltre, l'indirezione di una macchina virtuale è evidente nelle applicazioni web. Io non so voi, ma non ho mai visto un sito JSP più veloce di un sito PHP. Che poi il sito JSP sia "meglio" dal punto di vista della struttura, delle potenzialità e della grfica, è quasi sempre vero. Ma se c'è bisogno di un tempo di servizio molto basso, anche JSP è una scelta a rischio.

mattia.pascal

15-10-2006, 15:43

Si studia Java perchè è il linguaggio OOP per eccellenza(dopo smalltalk naturalmente).

dierre

15-10-2006, 15:53

non capisco perché ti poni il problema, tanto dovrai imparare a conoscerli tutti e tre, ed a questi aggiungine altri se vuoi stare al passo coi tempi e non farti trovare impreparato nel momento in cui andrai a lavorare :asd:

feboss

15-10-2006, 15:56

dierre

15-10-2006, 16:19

Guarda, io penso tu ti debba guardare un pò in giro perché non è assolutamente vero che poca roba è scritta in Java. Il problema che ti devi porre tu come programmatore è: che devo fare, e come lo devo fare, quale linguaggio mi conviene usare? Il resto è contorno.

lovaz

15-10-2006, 17:11

Non è che ti sei posto il problema perché hai iniziato l'università
e non riesci a capire il paradigma a oggetti? :asd:

Sai, la storiella della volpe che non riesce ad arrivare in cima all'albero...

PGI-Bis

15-10-2006, 17:24

Ed una risposta come questa merita un :D

Cmq, fammele notare queste corbellerie, dato che sono condivise da molti.

[omissis]

Eppure Java ha delle limitazioni oggettive che non possono essere dimenticate, e che vanno tenute in conto in molti contesti.

Ho scritto e riscritto più volte la risposta ma ogni volta saltava fuori un flame da paura :D. Siccome io sono laureato in legge e scrivo per lo più gestionali, per lavoro (roba semplice, divertente ma semplice se confrontata al software mega-super-spaziale-che-nun-se-po-fa-senza-er-c-ppiù-ppiù di cui si parla) non mi pare il caso di salire in cattedra e spiegare l'informatica a dei dottori in informatica.

franksisca

15-10-2006, 17:29

io trovo il java secondo al c solo per applicazioni videouliche.

Per l'univ. ho fatto un lavoro di gestione economica....molto grosso.

Ho usato Java e va benissimo......

Forse è vero, chi non capisce OO penserà che è stupido, ne ho fatto di litigate con chi dice che c è meglio a prescindere, ma semplicemente non è vero, il tutto dipende dai contesti......

telepuglia

15-10-2006, 17:34

Non sarò un guru, ma qualche esperienza l'ho accumulata ;)

Cosa discrimina l'utilzzatore di Vector da quello che usa BlockingQueue? :mbe:

Capito da solo: hai letto anche tu qua:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
:D

http://mathsrv.ku-eichstaett.de/MGF/homes/grothmann/java/bench/Bench.html

sbaglio o si testa fino al JDK 1.2? :read: un pò datato come test...si apprezzano comunque i miglioramenti dalla 1.0.2 e del jit.

Sull'uso errato delle classi thread safe si parla sui principali libri di programmazione, il primo che mi viene in mente è TIJ!

Non voglio discutere del linguaggio ideale perchè (a mio parere) non esiste, ma è errato affermare "Le performance sono disastrose in Java" o "Java è lento..."!

Occore guardare obiettivamente le tecnologie ed assumere decisioni razionali per la risoluzione del problema.

franksisca

15-10-2006, 17:36

Non voglio discutere del linguaggio ideale perchè (a mio parere) non esiste, ma è errato affermare "Le performance sono disastrose in Java" o "Java è lento..."!

Credo che con questo possiamo chiudere ;)

tomminno

15-10-2006, 17:42

telepuglia

15-10-2006, 17:48

Mi sono posto il problema, perchè non riuscivo a capire come mai queste persone si aggrappavano a java come se fosse la salvezza del mondo, quando poi in java vedo ben poco.troppo poco.

Cmq grazie Scoperchiatore, Finalmente qualcuno che mi ha dato una risposta decente

1. Cosa ti aspetti da Java?

2. Chi vuol salvare il mondo con Java?

3. Grazie per aver letto le risposte indecenti!

franksisca

15-10-2006, 18:08

Se è falso che Java è lento, mi spieghi come mai usando Eclipse con JVM 1.5.6 su un P3 1GHz e 512MB, mi sembra di avere un 486 con XP sopra?
Con Zend c'è un ritardo di quasi 2 secondi tra la digitazione su tastiera e la visualizzazione sullo schermo.
Eppure lo stesso PC non sente minimamente 3 sessioni di VS2005 aperte contemporaneamente e dire che VS2005 è decisamente pesante.

Come mai tutte le volte che provo ad usare un programma Java, la macchina rallenta notevolmente? Come mai lo stesso avviene puntualmente su tutti i computer che ho modo di utilizzare?
a pate che non concordo con questa analisi, ma hai mai provato poseidon???

dierre

15-10-2006, 18:26

a pate che non concordo con questa analisi, ma hai mai provato poseidon???

no vabbè, è vero su quello. Io ho iniziato a poter usare eclipse con il mio turion a 64 bit. Prima avevo un PIII e non ti dico la sofferenza.

PGI-Bis

15-10-2006, 18:42

Oè, ma son l'unico che ci mette venti minuti per scrivere una risposta? :D

Mi sono posto il problema, perchè non riuscivo a capire come mai queste persone si aggrappavano a java come se fosse la salvezza del mondo, quando poi in java vedo ben poco.troppo poco.

Cmq grazie Scoperchiatore, Finalmente qualcuno che mi ha dato una risposta decente

Scoperchiatore ti ha dato la risposta che volevi ti fosse data. Non è decente. Non ci arriva neanche vicino alla decenza. Sarebbe indecente anche per uno che non avesse studiato informatica.

"Livello di indirezione della JVM" non significa niente. E la straordinaria quantità di memoria che l'infida JVM sottrae al glorioso server è di 5-6 megabyte, il resto è quello che ci si mette dentro.

Scoperchiatore non può usare Java per la sua applicazione che occupa 2.6 gb di memoria ma non sa come e quando questo sia vero: ad esempio non può farlo se il sistema ospite è un Windows su x86 ma potrebbe se fosse Solaris.

Se deve eseguire un mucchio di volte una marea di operazioni su dati strutturati dovrebbe sapere che le macchine virtuali di IBM, Sun o BEA, se le operazioni sono ripetute e le strutture costanti, produrrebbero un codice macchina affatto diverso da quello che si otterrebbe dalla compilazione di un omologo in C.

Ciò non significa che la piattaforma Java non possa rivelarsi inadatta, anzi. Ad esempio, se l'applicazione è – come sembra – in real-time (18 ore di tempo per eseguire l'operazione), a meno di non rivolgersi all'onerosa piattaforma Java RT, la parte software va fatta in qualcos'altro. Parte software, intendiamoci: perchè non basta C a far sì che un programma produca sempre e comunque il proprio output nel tempo stabilito.

Posso immaginare che sulle macchine di Tommino la sola esecuzione del comando java -version richieda cinque anni per essere eseguita e subito dopo appaia belzebù in persona che, armato di forC++one, faccia strage dei presenti. Lo dico perchè su un fantasmagorico Athlon 1200 con un iperbolica quantità di RAM pari a 256 – diconsi duecentocinquantasei – megabyte di RAM Eclipse funziona bene. E addirittura ci gira pure NetBeans 5.

thebol

15-10-2006, 18:49

PGI-Bis

15-10-2006, 19:02

il 99% dei programmi bancari e assicurativi e scritto in cobol

Vero. Ho un cugino – fonte di grande rilevanza :D – che lavora nel settore e mi ha detto che praticamente lì usano tutti Cobol. Quello che mi chiedo è perchè non migrano. Sarà perchè c'è talmente tanta roba da riscrivere che non conviene?

telepuglia

15-10-2006, 20:22

Vero. Ho un cugino – fonte di grande rilevanza :D – che lavora nel settore e mi ha detto che praticamente lì usano tutti Cobol. Quello che mi chiedo è perchè non migrano. Sarà perchè c'è talmente tanta roba da riscrivere che non conviene?

Tutto vero! Il cambio di tecnologia spesso non giustifica la spesa!

E dopo il Cobol (nel settore bancario/assicurativo), Java (J2EE)!

thebol

15-10-2006, 20:32

Vero. Ho un cugino – fonte di grande rilevanza :D – che lavora nel settore e mi ha detto che praticamente lì usano tutti Cobol. Quello che mi chiedo è perchè non migrano. Sarà perchè c'è talmente tanta roba da riscrivere che non conviene?
per mille ragioni...
è abbastanza efficiente, sopratutto perchè gira in ambiente cics e i dati non devono fare troppi giri(anche se ce anche java per ambiente cics, da quel che ho capito)

per convertire tutto ci vorrebbero decenni
e stato talmente tanto usato che nei vari ced ci sono "framework" e metodologie collaudate da tempo

pero come linguaggio fa pena, e lo programmano in ambiente 3270(noi javisti lo chiamiamo mondo nero :asd: )

tomminno

15-10-2006, 21:20

a pate che non concordo con questa analisi, ma hai mai provato poseidon???

Si ci provai per i diagrammi UML della tesi, risultava completamente inutilizzabile. Sono passato a Star UML.
Per non parlare anche della differenza abissale tra Azureus e uTorrent.

telepuglia

16-10-2006, 13:11

Apriamo un 3D ufficiale su Java? :fagiano:

telepuglia

16-10-2006, 13:59

Io non so voi, ma non ho mai visto un sito JSP più veloce di un sito PHP. Che poi il sito JSP sia "meglio" dal punto di vista della struttura, delle potenzialità e della grfica, è quasi sempre vero. Ma se c'è bisogno di un tempo di servizio molto basso, anche JSP è una scelta a rischio.

Non ha molto senso :confused: perchè:

- JSP non migliora la grafica,
- i siti di cui parli sono probabilmente portali (...B2B o B2C) e non sono realizzati solo in JSP.

Scoperchiatore

16-10-2006, 15:32

Oè, ma son l'unico che ci mette venti minuti per scrivere una risposta? :D

Scoperchiatore ti ha dato la risposta che volevi ti fosse data. Non è decente. Non ci arriva neanche vicino alla decenza. Sarebbe indecente anche per uno che non avesse studiato informatica.

Ok, abbiamo capito che sei salito in cattedra :D
Diciamo che non è proprio il massimo dire che un altro è "indecente". Ora vediamo che motivazioni dai.

"Livello di indirezione della JVM" non significa niente.

Indirezione, in informatica, è la pratica di introdurre un livello aggiuntivo fra due componenti per ottenere un qualche beneficio. L'indirezione è il broker che investe per te su delle azioni, per esempio. Il broker è un livello di indirezione fra te e la borsa. Chiaro?

E la straordinaria quantità di memoria che l'infida JVM sottrae al glorioso server è di 5-6 megabyte, il resto è quello che ci si mette dentro.

La JVM parte con un quantitativo di memoria massimo fissato. Ne occupa molta per informazioni strutturate relative agli oggetti memorizzati (sai cos'è l'heap e lo stack per la JVM). Il discorso è lungo. Comunque, difficilmente una JVM prende solo 5-6 MB di RAM se carica un'interfaccia grafica.
Se hai un programma con bottoncini ed iconette, che all'apertura non occupa più di 5-6 Mb, mi posti uno screenshot dello stato del sistema e dell'applicazione? :)

Scoperchiatore non può usare Java per la sua applicazione che occupa 2.6 gb di memoria ma non sa come e quando questo sia vero: ad esempio non può farlo se il sistema ospite è un Windows su x86 ma potrebbe se fosse Solaris.

Certo, io ho un server con 3Gb di memoria che funziona con Debian stable perfettamente, kernel smp in quanto ha 4 CPU, e vado ad installare Solaris, uccidendo tutti gli altri servizi lì presenti, solo perchè voglio java...

In realtà Linux basta ed avanza, è che io ho bisogno di
1) controllare a mano la deallocazione
2) memorizzare le informazioni strettamente sufficienti per procedere con le elaborazioni.

Siamo d'accordo che queste due cosa JAVA non le dà?

Se deve eseguire un mucchio di volte una marea di operazioni su dati strutturati dovrebbe sapere che le macchine virtuali di IBM, Sun o BEA, se le operazioni sono ripetute e le strutture costanti, produrrebbero un codice macchina affatto diverso da quello che si otterrebbe dalla compilazione di un omologo in C.

Non lo sapevo. Grazie dell'informazione. Solo che il mio problema non è il tempo, ma la memoria.

Sai bene che un programma ha due tipi di complessità: spaziale e temporale. Rispetto ai dati in input, io impiego un tempo basso, ma occupo una memoria alta. Ora, dato che il tempo non era un problema, nel momento di scegliere come implementarlo abbiamo valutato solo la complessità spaziale. Come ben sai, in Java anche solo l'allocazione di un Hash si porta delle informazioni relative alla struttura dell'hash stesso, come il numero di elementi, i puntatori alla testa ed alla coda, e via dicendo.

Queste informazioni, facendoci un rapido calcolo, aumentano di circa 4 Gb la memoria occupata. Ora, potremmo anche sbagliare, ma considera che abbiamo fatto degli esperimenti in C aumentando di 1 byte la dimensione di uno dei dati che dobbiamo analizzare, ottenendo 50 Mb di memoria occupata in più sullo stesso set di dati. 1 solo byte sprecato = +50 Mb.

Se tu in un contesto del genere ti avventureresti ad usare Java, allora fammi dire che l'analisi di complessità non è il tuo forte.

Ci tengo a precisare che con Java avremmo sviluppato il programmino in 3 giorni, invece delle 2 settimane con C. Io non ho assolutamente nulla contro Java. Ma non credo che sia il linguaggio per tutte le stagioni, e sono convinto che in molti contesti C++ è un'alternativa migliore.

Ciò non significa che la piattaforma Java non possa rivelarsi inadatta, anzi. Ad esempio, se l'applicazione è – come sembra – in real-time (18 ore di tempo per eseguire l'operazione), a meno di non rivolgersi all'onerosa piattaforma Java RT, la parte software va fatta in qualcos'altro. Parte software, intendiamoci: perchè non basta C a far sì che un programma produca sempre e comunque il proprio output nel tempo stabilito.

Certo, 18 ore sono un real-time perfetto :D
E' un'applicazione non real time, ovviamente.
Cos'è la parte software? C'è una parte software e una parte hardware in un software? Tu forse parti dal presupposto che sia un'applicazione client server? In questo caso NON è così, è un programmino che gira solo sul server e aggrega dati.
Non basta C e non basta Java. Però se nel caso medio con C ci metto 3 ore, e con Java 6, meglio C

Posso immaginare che sulle macchine di Tommino la sola esecuzione del comando java -version richieda cinque anni per essere eseguita e subito dopo appaia belzebù in persona che, armato di forC++one, faccia strage dei presenti. Lo dico perchè su un fantasmagorico Athlon 1200 con un iperbolica quantità di RAM pari a 256 – diconsi duecentocinquantasei – megabyte di RAM Eclipse funziona bene. E addirittura ci gira pure NetBeans 5.

A me è sempre sembrato lento Eclipse.
Comunque, hai mai usato matlab? Matlab passo dalla versione 5 (o 6) alla versione 6 (o 7) ad una interfaccia in java (il core rimase in C).
Se hai tempo, scaricati entrambe le versioni e dicci se non noti qualche leggera differenza prestazionale.

Scoperchiatore

16-10-2006, 15:34

Non ha molto senso :confused: perchè:

- JSP non migliora la grafica,
- i siti di cui parli sono probabilmente portali (...B2B o B2C) e non sono realizzati solo in JSP.

- JSP è più carino graficamente, IMHO
- Indi?

Ora JSP è pure più veloce di PHP?

thebol

16-10-2006, 15:43

- JSP è più carino graficamente, IMHO

cosa vuol dire jsp è piu carino graficamente?
che ha una highlight syntax piu carina del php?
o che le taglib sono piu carine?

jsp come php genera html(o xml, o pdf, o quello che si vuole), un layout e carino a prescindere da essere jsp o php

Angus

16-10-2006, 15:50

Ma se c'è bisogno di un tempo di servizio molto basso, anche JSP è una scelta a rischio.

It's simple: just throw hardware at it.

Scoperchiatore

16-10-2006, 15:54

It's simple: just throw hardware at it.

Ovvero, aumentare la potenza o buttare il tutto dalla finestra?

dierre

16-10-2006, 15:57

- JSP è più carino graficamente, IMHO
- Indi?

Ora JSP è pure più veloce di PHP?

graficamente? O_o

Angus

16-10-2006, 16:51

Ovvero, aumentare la potenza o buttare il tutto dalla finestra?

Battuta simpatica, ma quello che ho detto dovresti averlo capito benissimo.

Per tutti gli altri che non lavorano nel campo: per le applicazioni web-oriented la scelta del linguaggio/piattaforma da utilizzare server-side non è mai influenzata dalle sue performances, ma principalmente dalla sua scalabilità.
In questo caso il confronto tra le performances 'velocistiche' di <VM a caso> e di <compilatore a caso> non c'entra nulla.

ps: l'hardware al giorno d'oggi costa relativamente poco.
pps: qualcuno su questo forum ti consiglierebbe caldamente di passare a Fortran per le applicazioni che progetti/sviluppi...

telepuglia

16-10-2006, 17:18

- JSP è più carino graficamente, IMHO
- Indi?

Ora JSP è pure più veloce di PHP?

:confused: ...spiegami...cos'è per te Flash ehm :doh: JSP?
direi "la velocità è nulla senza controllo" :D

telepuglia

16-10-2006, 17:44

La JVM parte con un quantitativo di memoria massimo fissato. Ne occupa molta per informazioni strutturate relative agli oggetti memorizzati (sai cos'è l'heap e lo stack per la JVM). Il discorso è lungo. Comunque, difficilmente una JVM prende solo 5-6 MB di RAM se carica un'interfaccia grafica.
Se hai un programma con bottoncini ed iconette, che all'apertura non occupa più di 5-6 Mb, mi posti uno screenshot dello stato del sistema e dell'applicazione? :)

La JVM non occupa tutta la memoria che potrebbe ma parte con una dimensione minima a meno di una diversa configurazione!

Solo che il mio problema non è il tempo, ma la memoria...
Però se nel caso medio con C ci metto 3 ore, e con Java 6, meglio C

Allora non ho capito il tuo problema!

Come ben sai, in Java anche solo l'allocazione di un Hash si porta delle informazioni relative alla struttura dell'hash stesso, come il numero di elementi, i puntatori alla testa ed alla coda, e via dicendo.
...Queste informazioni, facendoci un rapido calcolo, aumentano di circa 4 Gb la memoria occupata. Ora, potremmo anche sbagliare, ma considera che abbiamo fatto degli esperimenti in C aumentando di 1 byte la dimensione di uno dei dati che dobbiamo analizzare, ottenendo 50 Mb di memoria occupata in più sullo stesso set di dati. 1 solo byte sprecato = +50 Mb.

Quindi l'Hash "pesa" sugli 80 byte?

PGI-Bis

16-10-2006, 18:42

Ok, abbiamo capito che sei salito in cattedra :D

Al massimo salto su uno sgabello e già lì rischio il capogiro.

Uè, non ho detto "scoperchiatore è indecente". La risposta è indecente. Ma figurati se mi metto a dare dell'indecente a qualcuno. Non è un attacco personale a scoperchiatore, il mio. E' una feroce controffensiva a delle frasi che per me hanno un significato bizzarro. Se potessi userei Squeak per fare quello che devo fare in Java.

Dico che parlare di indirezione per una una jvm non vuol dire nulla perchè non trattiamo di una macchina virtuale tout-court: è una macchina virtuale che sappiamo eseguire certe operazioni. E se prendi la HotSpot – penso valga in generale per ogni JVM che abbia un JIT ma io ho letto solo di questa – il suo scopo è proprio quello di eliminare l'interprete del codice byte: un metodo invocato 1000 volte (impostazione predefinita per la jvm client) o 15000 volte (idem, jvm server) diventa un candidato per la compilazione in codice macchina. E, a differenza dei primi JIT di Sun, vale anche per i metodi virtuali.

Per dirlo in una frase, quanto più a lungo il programma gira tanto più eccezionale diventa l'esistenza di un passaggio intermedio tra il codice prodotto dalla compilazione dei sorgente ed il codice macchina. E' facile toccare con mano la cosa con un microbenchmark. Basta un metodo che faccia un qualche tipo di conto in un contesto in cui non possa essere considerato superfluo (perchè la JVM bara se capisce che un'espressione è costante e inutile). Conti il tempo di esecuzione di una chiamata a quel metodo. Poi lo chiami mille volte, fai uno sleep tanto per dare fiato al jit e poi invochi di nuovo lo stesso metodo contando un'altra volta il tempo di esecuzione. Noterai che non si tratta di un semplice "un po' più veloce": è enormemente più veloce.

Per la RAM occupata dalla JVM siamo d'accordo, ora. La JVM occupa una quantità di memoria per la sua esecuzione che non dipende dalla quantità di memoria richiesta per l'esecuzione dell'applicazione richiesta. Ma allora non puoi dire che è la presenza della JVM a farti temere che la RAM non ti basti. Che la JVM occupi 5-6 megabyte è cosa che puoi farti dire anche dal tuo sistema operativo. Fai un main che contiene solo un Thread.sleep, lanci, apri task manager e vedrai circa 6 megabyte di RAM associati al processo java.exe. Se vuoi l'interfaccia ti becchi il carico richiesto da Swing, che è di circa 6-7 megabyte se usi l'accelerazione DirectX e 10-11 se usi l'accelerazione OpenGL. Col trucco, perchè non si vede la parte di memoria consumata nella scheda video, di cui Swing fa esteso uso.

Un'applicazione Java che faccia uso di più di 2 gigabyte di memoria produce un'eccezione di esaurimento dell'heap su sistemi x86 Windows e Linux (kernel 2.4) anche se la memoria disponibile, compresa quella virtuale, sia maggiore. Solaris non è affetto da questo "problema". Personalmente non ho mai capito il perchè, almeno non con la precisione necessaria per discuterne. Credo dipenda da limiti dei suddetti sistemi operativi nell'allocazione di regioni contigue di memoria (l'heap della JVM deve essere una fetta unica). Comunque la versione a 64 bit per i relativi sistemi ne è immune (una volta Sun aveva pubblicato un test sul garbage collector parallelo della versiona a 64 bit di hotspot in cui allocava 300gygabyte ma non trovo più la pagina. Inizio a credere di essermelo sono sognato).

E' quantomeno improprio dire che la JVM occupa "molta memoria per le informazioni strutturate": sembra che, così per divertimento, ogni 3 byte utili la JVM ne infili 2 che non servono a niente, giusto per scassare le mandorle!

Io avrei usato Java in un contesto simile al tuo? Non posso dirlo. Da ignorante di complessità computazionale non possio fare altro che contare. Un Object nella HotSpot 1.5 pesa 8 byte, un Hashtable 40... e via con le somme – per le divisioni di solito mi rivolgo ad uno studio di matematici e fisici, è roba complessa. Se a voi risulta un'applicazione in Java occupi 6.6 gigabyte mentre quella in C ne occupa 2.6 allora, diamine, non si può dare torto ai numeri!

Circa la necessità che un software in real time (anche 18 ore sarebbero real time se fosse un requisito del software) abbia una controparte hardware, mi sembra presto detta. Non è che in C le somme si facciano in zero secondi. Il tempo impiegato dal programma per produrre l'output dipende dalla capacità dell'hardware di processare le istruzioni della sua architettura. Se hai un tempo da rispettare affinchè l'output della tua applicazione possa essere considerato valido non è sufficiente produrre il miglior codice possibile e immaginabile: devi anche avere la garanzia che quel codice macchina sarà eseguito in un tempo determinato o entro un tempo massimo determinato.

Per Matlab, se mi dici che è più lenta la versione Swing di quella precedente io posso anche crederci. In generale il problema non è affatto sul punto se le applicazioni Java siano o non siano lente. E' quando si va a vedere perchè i programmatori – gente che dovrebbe sapere quello di cui parla – sostengano questa lentezza.

Permettetemi un'amichevole battuta: posto che la JVM occupa 6 megabyte di RAM, se il semplice uso del linguaggio di programmazione Java comporta uno stupefacente incremento del 294% della memoria usata o il programmatore è un fenomeno da premio Turing quando usa C o è scarsissimo in Java! :D

[PS]
Tanto per non essere frainteso, l'amichevole battuta è solo questo, una battuta. Non mi permetterei mai di dare dello scarsissimo a nessuno. Nel caso riportato da Scoperchiatore è possibile che ci sia stata una stima diciamo "abbondante" ecco. Qui il primo degli scarsi è il sottoscritto.

Scoperchiatore

16-10-2006, 20:20

Battuta simpatica, ma quello che ho detto dovresti averlo capito benissimo.

Per tutti gli altri che non lavorano nel campo: per le applicazioni web-oriented la scelta del linguaggio/piattaforma da utilizzare server-side non è mai influenzata dalle sue performances, ma principalmente dalla sua scalabilità.
In questo caso il confronto tra le performances 'velocistiche' di <VM a caso> e di <compilatore a caso> non c'entra nulla.

ps: l'hardware al giorno d'oggi costa relativamente poco.
pps: qualcuno su questo forum ti consiglierebbe caldamente di passare a Fortran per le applicazioni che progetti/sviluppi...

Valutato anche quello. I requisiti di tempo non ci consentivano di imparare Fortran.

Non capisco invece, realmente, il senso della battuta. L'hw non costa tanto, ci sono, ma il carico di lavoro di un server/cluster di server è ovviamente importante e fondamentale per mantenere il tempo di risposta entro quei pochi secondi oltre i quali l'utente si stufa.

Mi stai dicendo, sostanzialmente, che è meglio fare overprovisioning che progettare bene e con le giuste tecnologie il servizio che vuoi offrire? Oppure mi sono perso qualcosa?

Non stiamo parlando di una "cosa", ovvero il giudizio sull'usare o meno un linguaggio/piattaforma, relativa al contesto? Oppure tu mi stai dicendo che in generale, devo valutare solo la scalabilità quando progetto un servizio web/affini, perchè tanto per le performances ci pensa chi compra l'hw?

Puntualizzo ulteriormente:la scalabilità è fondamentale, nulla da dire. Però non si parla di questo, si parla di "velocità" (dato che tutto il flame nasce da una mia affermazione in proposito). La mia idea, in questa discussione, è paragonare, a pari condizioni, Java e C/C++ e chiedere chi è più veloce.
Se penso a paragonare, in virtù di liberie che fanno la stessa cosa, la loro documentazione Java e quella C/C++, Java batte 10 a 0 i linguaggi di terza d'alfabeto.

Puntualizzo tutto ciò perchè mi interessa seriamente, oltre a difendermi da attacchi che talvolta ritengo esagerati (non il tuo caso), capire il punto di vista di chi probabilmente ha più esperienza di me.

Scoperchiatore

16-10-2006, 20:44

La JVM non occupa tutta la memoria che potrebbe ma parte con una dimensione minima a meno di una diversa configurazione!

Siamo d'accordo. Quindi in alcuni contesti è più che giusto spendere quei pochi byte di JVM per un determinato fine, in altri contesti quei pochi byte sono spreco.

Almeno su questo ci troviamo?

Allora non ho capito il tuo problema!

Io faccio O(2.000.000.000) di microelaborazioni (accesso a RAM, incrementi di contatore, creazione di records).
Tu non pensi che l'indirezione (io insisto a chiamarla così perchè è effettivamente un'indirezione, poi chiamatela come volete) della JVM in questi lavori risulti fondamentale?
Mi spiego meglio: se in C un confronto mi cosa 10 ed in Java 11, la differenza non è poca, perchè quell'uno di differenza va moltiplicato per 2.000.000.000 di confronti. E così via per tutte le operazioni minimali che vanno ripetute quelle 2 miliari di volte.

Io facendo un'analisi iniziale, ho abbandonato Java pensando a questo. Tu come avresti impostato quest'analisi? (tieni presente che non abbiamo voluto sprecarci troppo tempo, e forse abbiamo sbagliato)

Quindi l'Hash "pesa" sugli 80 byte?

Ogni elemento dell'hash pesa in media 50 byte di soli dati + 16 byte di ridondanza.
Hai un hash da 250.000 elementi, poco influenti nella memoria, ognuno dei quali contiene 2 hash di quel tipo
Ogni hash "interno" ha in media100 elementi, che però possono aumentare in funzione della giornata.
Calcolo: 250.000 x 2 x 100 x (50 + 16) = 3.300.000.000 che se non mi sbaglio sono 3 Gb.

Complessità teorica confermata nel caso reale, considerando anche le sovrastime e la variazione dei dati.

Sei d'accordo che, sotto questo punto di vista, il fatto che in Java l'overhead dovuto all'implementazione degli hash, anche solo al fatto che ogni elemento dell'hash ha più di 16 byte di overhead, porta a un programma insostenibile?
Prova a fare i calcoli cambiando quel 16 in un 20. Devi aggiungere altri 200 Mb di memoria.

Ora, potrebbe anche essere che le cose non sarebbero andate troppo male. Ma sinceramente, dubito proprio che si sarebbe avuta meno memoria occupata rispetto alla versione C. Soprattutto, in C posso controllare l'overhead. In Java come lo controllo? Mica posso reimplementare gli array per togliergli la proprietà "length" o sovrascrivere Object per togliergli i 4+4 byte dei semafori...

Inoltre, lo spazio di indirizzamento del kernel linux che ho a disposizione finisce a 3.2 Gb, quindi quello è un altro requisito inappellabile. Qui avere più HW non conta, non posso occupare più di 3.2 Gb, a meno di ricompilare un kernel in una macchina che serve anche ad altri scopi.

Scoperchiatore

16-10-2006, 21:23

Al massimo salto su uno sgabello e già lì rischio il capogiro.

Uè, non ho detto "scoperchiatore è indecente". La risposta è indecente. Ma figurati se mi metto a dare dell'indecente a qualcuno. Non è un attacco personale a scoperchiatore, il mio. E' una feroce controffensiva a delle frasi che per me hanno un significato bizzarro. Se potessi userei Squeak per fare quello che devo fare in Java.

Ok, chiaro ;)

Dico che parlare di indirezione per una una jvm non vuol dire nulla perchè non trattiamo di una macchina virtuale tout-court: è una macchina virtuale che sappiamo eseguire certe operazioni. E se prendi la HotSpot – penso valga in generale per ogni JVM che abbia un JIT ma io ho letto solo di questa – il suo scopo è proprio quello di eliminare l'interprete del codice byte: un metodo invocato 1000 volte (impostazione predefinita per la jvm client) o 15000 volte (idem, jvm server) diventa un candidato per la compilazione in codice macchina. E, a differenza dei primi JIT di Sun, vale anche per i metodi virtuali.

Chiaro anche questo. Ora, sicuramente potevo affidarmi a questa idea, ma non potevo esserne sicuro. Però io pensavo più a quell che ho scritto nel post di sopra, che credo sia leggermente diverso.
Io non devo fare per 2 miliardi di volte "addElement()" in una list.
Io devo fare x++ :D
Eppure ti posso assicurare che le dimensioni del problema richiedono talmente tanti ++ che sono loro la parte critica di tutto.

Credi che anche un semplice incremento viene trattato "meglio" da Java se vede che il programma ne fa larghissimo uso ?(ovviamente su dati diversi, nel senso che l'accesso al dato deve essere rapido)
E' una domanda, non un'uscita sarcastica.

Per dirlo in una frase, quanto più a lungo il programma gira tanto più eccezionale diventa l'esistenza di un passaggio intermedio tra il codice prodotto dalla compilazione dei sorgente ed il codice macchina. E' facile toccare con mano la cosa con un microbenchmark. Basta un metodo che faccia un qualche tipo di conto in un contesto in cui non possa essere considerato superfluo (perchè la JVM bara se capisce che un'espressione è costante e inutile). Conti il tempo di esecuzione di una chiamata a quel metodo. Poi lo chiami mille volte, fai uno sleep tanto per dare fiato al jit e poi invochi di nuovo lo stesso metodo contando un'altra volta il tempo di esecuzione. Noterai che non si tratta di un semplice "un po' più veloce": è enormemente più veloce.

Ok, questo mi è chiaro. L'avevo letto su un articolo, e me ne sono compiaciuto. Ma credo, come detto sopra, che nel mio contesto le cose fossero comunque troppo a rischio

Per la RAM occupata dalla JVM siamo d'accordo, ora. La JVM occupa una quantità di memoria per la sua esecuzione che non dipende dalla quantità di memoria richiesta per l'esecuzione dell'applicazione richiesta. Ma allora non puoi dire che è la presenza della JVM a farti temere che la RAM non ti basti. Che la JVM occupi 5-6 megabyte è cosa che puoi farti dire anche dal tuo sistema operativo. Fai un main che contiene solo un Thread.sleep, lanci, apri task manager e vedrai circa 6 megabyte di RAM associati al processo java.exe. Se vuoi l'interfaccia ti becchi il carico richiesto da Swing, che è di circa 6-7 megabyte se usi l'accelerazione DirectX e 10-11 se usi l'accelerazione OpenGL. Col trucco, perchè non si vede la parte di memoria consumata nella scheda video, di cui Swing fa esteso uso.

Era quello che intendevo. Come al solito, devi lanciare 4 bottoncini per scegliere che file aprire, forse non ha senso usare Java.
Se vuoi un IDE allora inizi a fregartene della RAM occupata.

Però, personalmente, il caso Matlab mi ha lasciato interdetto. Veramente Matlab diventa lentissimo quando ci montano sopra l'interfaccia Java. Si parla di 10-15 secondi in più di caricamento, per un totale di una ventina, su un computer non velocissimo (AMD 64@800 MhZ 512 Mb).
Personalmente, era tantino, quindi ho tolto quella versione reinstallando la vecchia

Un'applicazione Java che faccia uso di più di 2 gigabyte di memoria produce un'eccezione di esaurimento dell'heap su sistemi x86 Windows e Linux (kernel 2.4) anche se la memoria disponibile, compresa quella virtuale, sia maggiore. Solaris non è affetto da questo "problema". Personalmente non ho mai capito il perchè, almeno non con la precisione necessaria per discuterne. Credo dipenda da limiti dei suddetti sistemi operativi nell'allocazione di regioni contigue di memoria (l'heap della JVM deve essere una fetta unica). Comunque la versione a 64 bit per i relativi sistemi ne è immune (una volta Sun aveva pubblicato un test sul garbage collector parallelo della versiona a 64 bit di hotspot in cui allocava 300gygabyte ma non trovo più la pagina. Inizio a credere di essermelo sono sognato).

Ora ho capito quello che intendi.
I kernel dei vari SO dividono lo spazio indirizzabile in "kernel space" e "user space". Tale divisione va fatta a tempo di compilazione del kernel stesso, ed è quindi diciamo difficilmente modificabile. In Linux, da un po' di versioni, è possibile modificare qualcosa in questo senso.
Di default, sempre per linux, un utente ha uno spazio di indirizzamento massimo di 3.2 Gb. Anche avendo più RAM, anche avendo più swap, una tua applicazione non può occuapare più di quella RAM. Nella macchina che uso (ma anche nella mia, basta compilare il kernel in modo adatto) io posso indirizzare più di 2 Gb, ma non più di 3.2 Gb. Di contro, il kernel non puà usare per i suoi scopi più di 800 Mb

Considera che nella mia applicazione, ora gli hash interni sono "finti hash" avendo soltanto 4 buckets a testa. Quando gli davo un numero di buckets pari al numero medio di elementi in quegli hash (64 andava benissimo, partizionava in 2 l'insieme = ogni accesso a l'hash ha costo O(2), ed è potenza di due) la memoria arrivava a 3.2 Gb in 10-15 secondi....

Il discorso sui 64 bit è verissimo, non l'hai sognato. In una macchina a 32 bit non puoi indirizzare più di 2 alla 32 locazioni di memoria che sono proprio quei 4 Gb massimi di sopra (3.2 gb + 800 Mb)
Se hai 64 bit, puoi indirizzare fino a 2 alla 64 byte di locazioni di memoria ovvero un numero ad oggi enormemente elevato. Quindi sui 64 bit, il problema non sussiste, almeno ad oggi.

E' quantomeno improprio dire che la JVM occupa "molta memoria per le informazioni strutturate": sembra che, così per divertimento, ogni 3 byte utili la JVM ne infili 2 che non servono a niente, giusto per scassare le mandorle!

Se in c alloco con malloc una stringa da 10 elementi, ho allocato 10 byte più altri 8 byte che servono alla malloc per sapere dove sta quell'area di memoria e quanto è lunga
Overhead molto alto, su 18 byte allocati, 8 non li volevo.

La JVM usa malloc, od un suo parente stretto, ma deve anche lei sapere dove ha allocato e quanto è lunga l'area di memoria allocata.
Però se alloco una String di 10 elementi, devo aggiungere anche almeno 4 byte per il riferimento al comparator che leggo dalle api sun:

Field Detail
CASE_INSENSITIVE_ORDER

public static final Comparator CASE_INSENSITIVE_ORDER

A Comparator that orders String objects as by compareToIgnoreCase. This comparator is serializable.

Note that this Comparator does not take locale into account, and will result in an unsatisfactory ordering for certain locales. The java.text package provides Collators to allow locale-sensitive ordering.

Since:
1.2
See Also:
Collator.compare(String, String)

Ora, mi chiedo, dato che tutto estende Object, Object stesso non ha dei campi che io non uso ma che occupano memoria?
Sto scaricando il codice della JVM, perchè voglio vedere quanti byte occupa un Object. Mi ricordo che Object ha almeno 2 boolean che sono dei semafori,sostanzialmente. Se Java ha lo stesso problema di C (in quanto implementato su di esso) ovvero non esiste il tipo "bit" ma il tipo più piccolo occupa un byte, anche solo quei 2 booleani sono dei byte sprecati.

Quelle somma di sopra ti dovrebbero chiarire perchè mi sto attaccando anche ai byte.

Io avrei usato Java in un contesto simile al tuo? Non posso dirlo. Da ignorante di complessità computazionale non possio fare altro che contare. Un Object nella HotSpot 1.5 pesa 8 byte, un Hashtable 40... e via con le somme – per le divisioni di solito mi rivolgo ad uno studio di matematici e fisici, è roba complessa. Se a voi risulta un'applicazione in Java occupi 6.6 gigabyte mentre quella in C ne occupa 2.6 allora, diamine, non si può dare torto ai numeri!

Credo che se metti 40 invece di 16 nella formula di sopra, dovresti aumentare l'occupazione di circa 1 Gb

Circa la necessità che un software in real time (anche 18 ore sarebbero real time se fosse un requisito del software) abbia una controparte hardware, mi sembra presto detta. Non è che in C le somme si facciano in zero secondi. Il tempo impiegato dal programma per produrre l'output dipende dalla capacità dell'hardware di processare le istruzioni della sua architettura. Se hai un tempo da rispettare affinchè l'output della tua applicazione possa essere considerato valido non è sufficiente produrre il miglior codice possibile e immaginabile: devi anche avere la garanzia che quel codice macchina sarà eseguito in un tempo determinato o entro un tempo massimo determinato.

Ovviamente, ti parlo a parità di HW. Quello che io posso fare è far funzionare un programma con quell'hw. In C, facendo i vari calcoli, sapevo di farcela, in Java non ne ero sicuro.

Per Matlab, se mi dici che è più lenta la versione Swing di quella precedente io posso anche crederci. In generale il problema non è affatto sul punto se le applicazioni Java siano o non siano lente. E' quando si va a vedere perchè i programmatori – gente che dovrebbe sapere quello di cui parla – sostengano questa lentezza.

Credo per esperienza. Ti ripeto che dopo 5 anni a C++, Turbo pasquale e Basic / VB sono passato a Java. E' sempre stato per me un linguaggio spettacolare: pulito, strutturato, rifattorizzante, perfetto per i patterns, e via dicendo.

Però mediamente, quando sviluppo qualcosa in C la vedo "scattare", in Java mi sembra sempre lentina. Altra gente condivide questa impressione con me. Non dico che ho per forza ragione, anzi. Però l'impressione è quella

Permettetemi un'amichevole battuta: posto che la JVM occupa 6 megabyte di RAM, se il semplice uso del linguaggio di programmazione Java comporta uno stupefacente incremento del 294% della memoria usata o il programmatore è un fenomeno da premio Turing quando usa C o è scarsissimo in Java! :D

No, sono soltanto i dati che sono tanti. Quando la mole è ampia, è inutile girarci troppo intorno. Come quando stai tentando di risolvere un problema a cui puoi ridurre il problema della fermata (dato che hai tirato fuori Turing, mi è venuto in mente questo esempio :D) è inutile andare avanti. E' irrisolvibile, java, C o Cobol.

[PS]
Tanto per non essere frainteso, l'amichevole battuta è solo questo, una battuta. Non mi permetterei mai di dare dello scarsissimo a nessuno. Nel caso riportato da Scoperchiatore è possibile che ci sia stata una stima diciamo "abbondante" ecco. Qui il primo degli scarsi è il sottoscritto.

So bene che il contesto è strano e sconociuto ai più, quindi molti di voi potranno avere difficoltà a capire cosa mai deve richiedere così tanta memoria. Considerate che è parte della mia tesi di laurea, quindi lavoro di ricerca, quindi cosa non usuale. Però realmente, non ho scritto numeri a caso, se volete vi posto il track dell'esecuzione del programma :D

Ho riguardato il codice (neanche due migliaia di righe, pochissima roba) in lungo ed in largo, non mi sfuggono puntatori e faccio 5 malloc contate e stra-calibrate. E' veramente difficile che abbia fatto un qualche errore per occupare 1 Gb di ram inutilmente, però potrebbe essere, nulla è da escludere a priori.
Solo che l'algoritmo è quello, se lo riscrivo in Java rifarò lo stesso errore :D

PGI-Bis

16-10-2006, 21:37

Per vedere le dimensioni degli oggetti su una macchina virtuale Java – cioè su quella di Sun, per le altre non ho mai provato – puoi usare l'opzione -Xaprof. Se lo provi su un programma "vero" ti conviene indirizzare l'output su un file:

java -Xaprof bla.bla.Main >> ilpaccone.txt

Le dimensioni sono in byte.

tomminno

16-10-2006, 22:51

Che la JVM occupi 5-6 megabyte è cosa che puoi farti dire anche dal tuo sistema operativo. Fai un main che contiene solo un Thread.sleep, lanci, apri task manager e vedrai circa 6 megabyte di RAM associati al processo java.exe. Se vuoi l'interfaccia ti becchi il carico richiesto da Swing, che è di circa 6-7 megabyte se usi l'accelerazione DirectX e 10-11 se usi l'accelerazione OpenGL. Col trucco, perchè non si vede la parte di memoria consumata nella scheda video, di cui Swing fa esteso uso.

A me il processo javaw.exe porta via 60MB, indipendentemente dall'applicazione. Sarà magari memoria allocata ma non usata...

PGI-Bis

16-10-2006, 23:05

A me il processo javaw.exe porta via 60MB, indipendentemente dall'applicazione. Sarà magari memoria allocata ma non usata...

Ammazza :eek:. Prova a compilare un programma che non fa niente, tipo:

public class Main {
public static void main(String[] args) throws Throwable {
Thread.sleep(5000);
}
}

compili, poi apri task manager e da console lanci: javaw Main. Se si ciuccia 60megabyte lo stesso c'è qualcosa che non va.

Angus

17-10-2006, 12:10

Valutato anche quello. I requisiti di tempo non ci consentivano di imparare Fortran.

Non capisco invece, realmente, il senso della battuta. L'hw non costa tanto, ci sono, ma il carico di lavoro di un server/cluster di server è ovviamente importante e fondamentale per mantenere il tempo di risposta entro quei pochi secondi oltre i quali l'utente si stufa.

Mi stai dicendo, sostanzialmente, che è meglio fare overprovisioning che progettare bene e con le giuste tecnologie il servizio che vuoi offrire? Oppure mi sono perso qualcosa?

Affatto, intendevo dire proprio quello che tu stesso aggiungi più sotto:

Puntualizzo ulteriormente:la scalabilità è fondamentale, nulla da dire. Però non si parla di questo, si parla di "velocità" (dato che tutto il flame nasce da una mia affermazione in proposito). La mia idea, in questa discussione, è paragonare, a pari condizioni, Java e C/C++ e chiedere chi è più veloce.
Se penso a paragonare, in virtù di liberie che fanno la stessa cosa, la loro documentazione Java e quella C/C++, Java batte 10 a 0 i linguaggi di terza d'alfabeto.

In altre parole: qui nella discussione/(flame?) le applicazioni 'enterprise' e PHP non c'entrano niente.

Nel caso di Fortran tu hai rinunciato al confronto per esigenze di tempo. E' lo stesso motivo per cui se hai un team 'J2EE oriented' e i tempi sono ristretti, sai che potrai progettare/sviluppare *bene* (perchè questo non dipende dalla VM/compilatore che sia) e avrai la sicurezza che la piattaforma usata non avrà problemi a soddisfare requisiti come il tempo di risposta perchè estremamente scalabile.

Circa un anno fa, o forse più, c'era un thread sul confronto tra vari linguaggi (splendidamente 'interpretati' da alcuni del forum) nelle performance espresse su un algoritmo come il Crivello di Eratostene. la JVM aveva un tempo di risposta di un ordine di grandezza superiore al C. Sospetto che però tale 'osservazione' dipendesse in una certa misura anche dalla poca bravura del sottoscritto.

Detto questo mi defilo dalla discussione perchè credo che sia lapalissiano che un buon compilatore C (e forse C++) permetta, se questo fosse un requisito, un bassissimo overhead in 'spazio' ed in seconda battuta in 'tempo'. Ma non per questo C/C++ sono assolutamente migliori di Java/.Net.

Una postilla dedicata all'autore del Thread: un buon programmatore sa utilizzare gli strumenti giusti al momento giusto.

Scoperchiatore

17-10-2006, 21:17

Una postilla dedicata all'autore del Thread: un buon programmatore sa utilizzare gli strumenti giusti al momento giusto.

Diciamo che questo può essere il sunto di tutta la discussione.