Newsgroup: it.comp.java
Titolo: Compilatori native e gcj

Vorrei sapere :cosa ne pensate del gcj?
L'avete mai provato? 
in generale come valutate quel tipo di compilatori?
-- 
/////////////////////////////////////////////////////////////////////
/
/	 
cyber...@libero.it
   # ICQ N° 70608137                           
/     	   D.A.V.I.D. is A Vision of Inner Demons
/	
/	Redattore di Luci ad Ovest e membro della Harlequin crew
/	Visita Luci ad Ovest! (
http://www.gilda.it/luciadovest
)
/	Presente nella computazione del progetto  S.E.T.I@Home
/	   (
http://setiathome.ssl.berkeley.edu/
)
/////////////////////////////////////////////////////////////////////

 in generale come valutate quel tipo di compilatori?
Lo uso qualche volta in Linux. Non ci ho mai fatto nulla di "serio", ma
mi pare valido.

Io non ho provato ancora, ma sinceramente penso un programma java debba
rimanere bytecode portabile. Quello che cambierà e migliorerà sicuramente
sono le JVM.
Symantec, p.e., sta sviluppando una nuova JVM chiamata Excalibur
(
http://industry.java.sun.com/javanews/stories/story2/0,1072,16266,00.html
)
che è molto più veloce sia di HotSpot che della JVM di IBM.
Si pensa (ma questo è da dimostrare sul campo) che sia addirittura possibile
avvicinare le prestazioni del C++.
Se non è proprio vero, comunque penso che margini di miglioramento siano
ancora possibili, tali sicuramente da rendere Java molto più veloce almeno
del Visual Basic e di C#!
--
----------
Lello Mele
Via San Sebastiano, 22
84036 Sala Consilina (SA)
P.Tel.:0347/643.35.25
HOMEPAGE:
http://www.programmazione.it
http://tcp.come.to
eMAIL:
v...@libero.it
me...@programmazione.it
PROFILE:
http://www.programmazione.it/index.php?entity=eauthor&idAuthor=83
-------------
"Esistono due modi per elaborare il progetto di un software.
 Il primo consiste nel renderlo semplice al punto tale che non
 manifesti lacune evidenti. Il secondo consiste nel renderlo
 complicato al punto tale che non manifesti lacune evidenti.
 Il primo metodo e' di gran lunga piu' difficile." [C.A.R. Hoare]

Un ragionamento semplice semplice:
1) Secondo te perchè la  Sun non ha creato o finanziato un compilatore di
codice nativo, almeno per  le piattaforme più importanti Solaris e Windows?
le risorse
umane e tecniche o semplicemente finanziarie (a parte che poteva trovare uno
sponsor) non gli
mancano sicuro.
2) Quale è il motivo del fallimento del progetto SuperCede di Asymetrix, che
ti ricordo era un compilatore di codice nativo Java/C++ (davvero ottimo
secondo me!) venduto poi ad una
anonima software house (Jove)??
3) Perchè Symantec o IBM,  dovrebbero investire in una improbabile JVM
migliore quando invece potrebbero semplicemente creare un compilatore (ed
entrambe hanno la tecnologia per
farlo) o al limite tenere semplicemente conto del fatto che gìà Sun sta
investendo in una JVM più performante
(HotSpot, integrata in jdk 1.3)?
4) Come mai, nonostante le aspettative di larga parte del mercato che vuole
proteggere gli investimenti fatti (leggi: vuole impedire che si possa
decompilare facilmente un file .class)
NESSUNO dei grandi è sceso ancora (e nessuno ha intenzione di scendere da
quello che si vede) nell'arena dei
compilatori nativi???
LM

 termini di portabilità. ;)
una tua opinione, un po' naive, ma comunque un'opinione.
Ancora, per l'ennesima volta, ricordo a tutti i partecipanti al ng che 
la storia delle prestazioni va inquadrata in un'ottica server side o 
client side. Nel primo caso è possibile (e succede, molto più spesso di 
quanto si creda) che un programma java superi le prestazioni di un 
analogo C++ (un programma OO, non un programma strutturato alla c) per 
tutta una serie di motivi legati soprattutto alla gestione della 
memoria, mentre nel secondo caso java non è il linguaggio ideale anche 
se si sono fatti molti miglioramenti in tal senso.
Ricordo anche che compilatori nativi esistono (TowerJ), e che in vari 
confronti si è visto che comunque VM molto ottimizzate eguagliano le sue 
prestazioni o addirittura le superano (ed infatti TowerJ ha un mercato 
di nicchia molto... ridotto).
Al di là di questo, abbastanza oggettivo, ognuno la può pensare come 
vuole e affermare le sue 'verità' come meglio crede.
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere,
  bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry
__________________________________________________________________________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enterprise Java Consulting
@mail: 
ugo.l...@flashnet.it
@work: 
ugo.l...@sun.com
Home Page: 
http://www.ugolandini.net
Fax Phone: 06/233207542
Cell Phone: 0347/6310749 - 0347/4783580
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 writes:
[... omissis ...]
UL> la storia delle prestazioni va inquadrata in un'ottica server side o 
UL> client side. Nel primo caso è possibile (e succede, molto più spesso di 
UL> quanto si creda) che un programma java superi le prestazioni di un 
UL> analogo C++ (un programma OO, non un programma strutturato alla c) per 
UL> tutta una serie di motivi legati soprattutto alla gestione della 
UL> memoria, mentre nel secondo caso java non è il linguaggio ideale anche 
UL> se si sono fatti molti miglioramenti in tal senso.
E' per il secondo punto che un compilatore nativo sarebbe una pacchia,
decisamente più utile  dei just-in-time compiler.  
Se no ti ritrovi a dover usare  il VB ...
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: sierra alfa india november tango AT echo november golf DOT india tango