Newsgroup: it.comp.java
Titolo: calcoli pesanti

Dovendo sviluppare una applicazione per effettuare lunghi e pesanti calcoli
di statistica conviene usare il linguaggio Java?
Mi terrorizza un po' il discorso che si fa sulla sua lentezza (non so se sia
fondato o meno) a causa dell'interprete.
Compilando il bytecode si possono raggiungere miglioramenti sensibili?
Dove trovo comunque un compilatore per passare da bytecode a un eseguibile
per Intel/Windows2000 ?
Grazie in anticipo
Paolo Covelli

I problemi di Java per la sua lentezza è una realtà, quindi ti sconsiglio
di fare tale programma a meno che tu non abbia un processore assai potente.
Cmq non credo che riuscirai a trovare un compilatore per windows dato che
il bytecode è già un "eseguibile" per la JVM.
Semmai devi scaricarti dalla sun tale strumento.

 ha scritto nel messaggio
news:01c0354f$097dc5e0$ca8d1997@libero...

I problemi sulla lentezza e pesantezza sono riscontrabili soprattutto nei
programmi che fanno ampio uso delle librerie grafiche (specie le swing).
Se un'applicazione java lavora in modalità a carattere ed esegue algoritmi
"macina numeri", le sue prestazioni potrebbero essere non molto dissimili da
quelle di un programma scritto in linguaggio nativo.
Per quanto riguarda il compilatore, tutte le macchine virtuali recenti,
hanno incorporato un compilatore just-in-time che traduce a run-time il
codice interpretato in codice macchina nativo (per questo motivo i programmi
java tipicamente sono un po' lenti a partire...), quindi credo che un
compilatore statico non sarebbe di grande aiuto.
Se hai molti soldi da spendere, sono comunque disponibili (a
pagamento)alcuni compilatori statici. Uno di questi è towerj (
www.tower.com
)
che traduce il codice java in codice c ma non è pienamente compatibile con
il jdk (mi sembra che non supporti nessun tipo di libreria grafica)
Io ti consiglio di utilizzare la macchina virtuale IBM versione 1.3 (è
gratuita e c'è anche per win2000 
www.ibm.com/java/jdk
); in alcuni benchmark
(vedi 
http://www.javalobby.org/features/jpr/
) è risultata molto performante
proprio nelle applicazioni numeriche.
Fabio

 wrote in message 8s7r2k$ft9$1...@nslave2.tin.it...


Le operazioni sui dati nativi di Java (int, float, double, etc..) sono
discretamente veloci e comunque esistono vari metodi per velicizzare le
operazioni più diffuse in statistica (tipo lookup tables per il
chi-quadrato). Tempo fa avevo trovato un sito che offriva alcuni packages
atti allo scopo, purtroppo però non saprei dove ritrovarli :-( .
Dove Java è davvero lento è ogni volta che si passano "puntatori" in giro
(ove per puntatore intendo il riferimento ad un'oggetto) e quando in
generale si usano le classi (tipo Integer al posto di int).
Per contro Java ha la classe java.math.BigDecimal che "elimina" alcuni dei
problemi più osceni quando si trattano i numeri in virgola mobile tramite C:
l'arrotondamento pseudocasuale basato su quella porcheria (a mio avviso)
della notazione esponente+mantissa.
Il mio consiglio è:
 - Se vuoi la massima velocità e al diavolo la precisione buttati sul C (o
meglio ASM).
 - Se vuoi un approccio più lineare al problema accettando uno scadimento
del 10-40% delle prestazioni usa Java.
ByEZ,
MindFlavor.
--
MindFlavor's Site 
http://web.tiscalinet.it/mindflavor
Mail: mailto:
mindflav...@hotmail.com

Un Hello World in java sul mio computer parte con una differenza di due
secondi rispetto ad un analogo in C.

 ha scritto nel messaggio
news:01c035e9$61b86360$LocalHost@libero...


 fondato o meno) a causa dell'interprete.
Usa una buon JIT e non ti preoccupare troppo dell' "HIPE" sulla lentezza di
java.
Dalla mia esperienza personale (un raytracer, scritto in C, portato in Java)
ho potuto constatare che:
- Java sui floating point e' paragonabile al 98% al C compilato ed
ottimizzato (VC++6) per il processore ospite.
- Java e' PIU VELOCE di C (anche del 30-40%) su codice int/float misto e in
ogni caso in cui tu debba effettuare cast tra int/float/double. Da C, puoi
ottenere velocita' paragonabili al Java solo se ti scrivi i cast in asm
(tipo _float2int()) o se compili con opzioni abbastanza nascoste e
sconsigliate dalla stessa M$.
- Java e' abbastanza lento sull'output video, ma qui si aprirebbe un
argomento troppo grande da trattare su un NG. Ci sono, ovviamente, sistemi,
trucchi, accorgimenti per scrivere una buona applicazione che non faccia
rimpiangere il gui toolkit del sistema ospite.
Ciao,
Michele Puccini - ClassX Development Italy
--



Il fatto è che un misto di int e float in C non è possibile, in quanto
internamente vengono effettuate delle conversioni implicite.
In più si può aggiungere che la libreria matematica del C - come tutta la
libreria in genere - è implementata in modo schifoso. 
Inoltre l'utilizzo del codice asm diminuisce la portabilità del programma.
Per quanto riguarda MS mi pare che sia troppo impegnata a rendere il Visual
C++ un linguaggio antagonista al C++ - considerato scadente dalla stessa -
piuttosto che occuparsi di definire propri standard del C.
Forse non ho ben capito io ma consideri C e C++ come la stessa cosa?

> Forse non ho ben capito io ma consideri C e C++ come la stessa cosa?
Se non sbaglio SONO la stessa cosa (dal punto di vista delle prestazioni),
infatti un sorgente C++ viene tradotto in C dal compilatore prima della
compilazione effettiva

 Tel.
(+39)-0587-749206
  Fax.
(+39)-0587-749206
  WEB: 
http://www.classx.it
  <
============================================================================

Questo č vero, ma i nuovi compilatori stanno tentando di creare di superare
la fase di riduzione al linguaggio C a causa di problemi di ottimizzazioni.
Cmq io non intendevo sotto forma di prestazioni- su questo hai ragione tu -
ma sotto forma di sintassi e programmazione in generale. Molti sostengono
che la differenza tra C e C++ č data dall'aggiunta della keyword class  e
pensano di programmare nel suddetto linguaggio e pensano di padroneggiare
il suddetto linguaggio solamente imparando questo nuovo aspetto.
Se sono stato offensivo chiedo scusa.

Per questo ho scelto java.
Anche questa è un'ottima scelta.


 Paolo Covelli
--
"Science is like sex: sometimes something useful comes out,
                      but that is not the reason we are doing it"
                                                -- Richard Feynman

 writes:
PC> Dovendo sviluppare una applicazione per effettuare lunghi e pesanti calcoli
PC> di statistica conviene usare il linguaggio Java?
Se proprio  devi, usa i  tipi (e non  le classi che li  incapsulano) e
tanto la keyword final per i metodi.
Altrimenti cambia  linguaggio. Col C  puoi ottenere (al prezzo  di una
progettazine ed  uno sviluppo più costosi)  programmi tanto flessibili
quanto quelli in Java.
E  magari cerca  di  far girare  il programma  su  un bel  RISC, se  è
possibile.
PC> Mi terrorizza un po' il discorso che si fa sulla sua lentezza (non
PC> so se sia fondato o  meno) a causa dell'interprete.
L'interprete  bytecode  è  indubbiamente  meno  veloce  di  un  codice
interpretato direttamente e quello  Java è particolarmente lentino per
quel  che riguarda  le  invocazioni dei  metodi.   Definendo i  metodi
'final' hai uno speedup, ma  Java non è un linguaggio meraviglioso per
via delle  prestazioni a runtime,  anche Gosling sapeva  benissimo che
esistono C e FORTRAN.
\begin{avviso}
 
Attenzione: rispondo ad ogni invio  di pubblicità non richiesta o spam
di qualsiasi  altro genere con  un messaggio al provider  di competen-
za.  Ai sensi  della  legge sulla  privacy  NON avete  il permesso  di
utilizzare i miei dati per questi scopi.
\end{avviso}
+----------------------------------------------------------------+
| Gian Uberto Lauri * "So, are you working on fixing that bug    |
| 
sa...@eng.it
      *  *now* or leaving it until later ?" - YES  |
+----------------------------------------------------------------+

 writes:
CED> BigDecimal perche' anche se puo'  piacere molto a chi non conosce
CED> il calcolo numerico e  odia la forma mantissa+esponente -di fatto
CED> somiglia molto  al comportamento  dei nukeri usati  dai cobolisti
CED> delle banche-
Credo che derivi più dal LISP  che dal COBOL, ed esista per affrontare
non il calcolo numerico pratico ma questioni teoriche.
