LINUX

[Petrik Gergely]

On Tue, 29 Mar 2005, hwsw famulus wrote:

> Megpedig azert mert a C forditonak beadhato
> kod kevesbe kotott mint amit a JVM-nek beadhatsz.
> Azaz nehezebben optimalizalhato, mert a bemenete
> lehet az "egesz vilag", szamtalan variacioban
> Ezzel szemebn a JVM szintjen mar csak
> egy szuk kis vilag a bemenet amire a futtatast optimalizalni kell
> Konkrete csak a JVM buta kis utasitas keszletere.....

a binaris szamok halmaza is vegtelen, akarcsak a decimalisake.

> Avagy rosszul latom?

attol meg, hogy buta az utasitaskeszlet, sztem nem biztos, hogy 
konnyebben optimalizalhato, sot! es amit a jvm megeszik, az 
pont ugyanakkora vilag, mint amit javaban leirhatsz, marpedig 
a java nyelv nemigazan tartalmaz szignifikans korlatozasokat a 
c-hez kepest. a pointerek hianyoznak belole, helyette 
referenciazas megy orrba-szajba, de ezt nem erzem lenyegi 
kulonbsegnek. persze erzesre sokminden maskepp van, mint 
valojaban, de engem ez az erveles nem nagyon gyozott meg.

a problema ugyanaz, mint az assembly kod optimalizalasanal: ha 
azt nem tudjak megcsinalni tisztessegesen (ezalatt ertsd: 
elegge altalanosra es hatekonyra) semmilyen architekturara, 
akkor a jvm gepi kodjat miert tudnak (plane futasi idoben) 
jobban optimalizalni? a java2jvm kod transzlacio meg nem latom, 
miert lenne jobban optimalizalhato, mint a c2asm, mikor mindket 
magasszintu nyelv azonosan altalanos.


a gcc elleni 90%-kal kapcsolatban is jo kerdes, hogy milyen 
oprendszeren mertek a dolgot, meg mennyi gcc-s optimalizalo flag 
volt bepruttyentve versus a java forditoba mennyi optimalizalast 
epitenek bele alapbol, kikapcsolhatatlanul.

ha elsiklottam a thread lenyegi reszei folott, akkor bocsanat:
nem olvastam minden hozzaszolast.

--
G