Java fordítása gépi kódra. Gyors lesz e ?
2010-07-07T11:09:16+02:00
2010-07-10T10:08:46+02:00
2022-07-03T12:00:27+02:00
  • Ez picit nekem is gyanús. Én jó pár éve láttam utoljára C++ vs Java tesztet, akkor úgy 15% volt az eltérés a C++ javára. Ehhez képest ez nagyon soknak tűnik.
    Mutasd a teljes hozzászólást!
  • Miért, az nem számít?


    A benchmark része, tehát számít. Ha 0,5-10mp ideig tartó folyamataink vannak, és minden új folyamat esetén újra kell indítani a JVM-et, akkor arra a feladatra nem alkalmas a Java - és ez közismert. Ennek ellenére az említett benchmark kevés kivétellel 10 másodpercen belül befejeződő feladatokról szól...

    A rövid tesztidők ellenére a -server opció volt használva, így kényszerítve van a JVM, hogy lassabban induljon, mivel nem az elindulás sebességére optimalizált kód indul el, hanem a több napos futásra optimalizált kód (szerver felhasználás!)... az más kérdés, hogy ennek ellenére fele esetben csak a -O2/-O3 optimalizált kód volt gyorsabb, mint a lassan induló és feladatra nem optimalizált virtuális gépen futó Java kód... :)
    Mutasd a teljes hozzászólást!
  • a JVM elindulásának idejét


    Miért, az nem számít?
    Mutasd a teljes hozzászólást!


  • Ez a benchmark két dolgot mér:
    * a JVM elindulásának idejét
    * a készítő hozzáértésének szintjét

    A `java -server` nem gyorsabb, ebben az esetben a JVM hosszabb futásidőre és lassabb indulásra rendezkedik be, a tesztben pedig rendre 0.5-10mp közötti idők szerepelnek, amely nem elég arra, hogy a JVM (főleg a -server használata okán) igazán lendületbe kerüljön és a HotSpot mérései alapján a JIT optimalizálni tudjon.

    Továbbá míg a GCC fordításra 5 különféle módot mér, a JVM ~100-200 paraméteréből egyet se alkalmaz, még a fontosabb egytucat paramétert se, pedig ezekkel lehet a JVM-et a feladathoz hangolni...

    Átlagos C++ és átlagos Java kód esetén manapság a Java gyorsabb. Végletekig optimalizált C++ és Java kód esetén a C++ gyorsabb. A végletekig optimalizált kód nagyságrendekkel drágább.
    Mutasd a teljes hozzászólást!
  • Akkor meg ne aggódj. Ahogy látom nem fogsz kétségbe esni, ha egy programot véletlenül nem Java nyelven kell megírni (mondjuk a sebesség miatt). Legfeljebb kicsit túrni kell a dokumentációt, de ez ha jól sejtem a legjobbakkal is megesik.
    De ha profi "Jávás" vagy akkor feltételezem abból is megélsz, nem kell más nyelvekhez nyúlni.
    Mutasd a teljes hozzászólást!
  • Azt még megemlítem, hogy a következő két félévben Java lesz
    Mutasd a teljes hozzászólást!
  • Delphi 1 év
    C# 1 év
    Html néhány hónap
    C 6 hónap
    C++ 5 hónap
    Java 1 hónap
    A többi említésre sem méltó.

    Ezek idősorrendben vannak kezdés szerint. Most leszek másodéves mérnök informatikus a BME-n.
    Mutasd a teljes hozzászólást!
  • Nagyon jó kis desktop alkalmazásokat lehet(ne) készíteni javában.
    A netbeans Pl. pure java és nagyon jó kis desktop alkalmazás.

    Ami akadály, az egyrészt az, hogy a java nem úgy épül be a windowsba (és máshová) mint Pl. a .NET, hanem minden alkalmazás viszi a saját javás környezetét. Másrészt, a desktop progik 99%-a windowson fut, ott pedig ott van a C# és a .NET, vagy a Delphi. Egyszerűen praktikusabb windows alatt egy .NET-es desktop progit csinálni mint egy javásat. Nem kell JVM-et hurcolni, a windows.forms is jóval inkább kézreáll és ismertebb is mint a swing, az SWT-ről nem is szólva. És a 3.x-től már van WPF is.

    A régebbi progiknak pedig ott volt a Delphi. Kellemes RAD, az Object Pascal sem volt rossz nyelv a maga idejében, a lefordított progi úgy 4M körüli (helló világnál legalábbis) és nem kell neki semmi futtatókörnyezet.
    Mutasd a teljes hozzászólást!
  • Csendben kikapcsolni a gépet
    még szép :D, ráérünk kockulni télen is.
    Mutasd a teljes hozzászólást!
  • Mit kellene csinálni? Csendben kikapcsolni a gépet mert volt már egy (pár) topic amiben a java és a c++ szerepel?
    Mutasd a teljes hozzászólást!
  • Hihetetlen, hogy 1-2 havonta mindig előkerül egy ilyen flame topic, aztán mindenki elmondja a saját igazát és persze kb. mindig hasonló hozzászólások születnek.
    Mutasd a teljes hozzászólást!
  • Szerintem ez igy csak szajkarate. Honnan vettetek a 20%-ot, meg a tobbit ? A valodi elet egy kicsit mas jellegu szamokat ad, ha nem is pont mindig valamelyik tabor szaja ize szerint. Milyen teszt az, ami arra epit, hogy a fordito kioptimalizalja belole a kodot, mert valojaban nem csinal semmit ?

    Benchmark (pl)

    Altalaban veve a nativ c++ kod ket, haromszor gyorsabb a java valtozatnal, ami a java alkalmazasi teruleten nem mindig szempont... Az uzleti logikanal a hordozhatosag, es platformfuggetlenseggel szemben egy kis sebessegvesztes aligha erv... Viszont erdemes megnezni, milyen desktop alkalmazasok keszultek javaban... Nem igazan jellemzo, hogy tul nepszeruek lennenek az atlag felhasznalok koreben, nem?
    Ami a platformfuggetlenseget illeti, a java egyetlen olyan teruleten kerult szeles korben alkalmazasra, ahol valoban nagy szamu telepitett valtozat van, es az a j2me (mobil), itt viszont katasztrofalisan leszerepelt, nincs ket olyan mobil, ami kompatibilis lenne - a mobil jatekok jellemzoen akar majdnem szaz kulonbozo keszulekre is portolni kell a kompatibilitasi problemak miatt.
    Mutasd a teljes hozzászólást!
  • Egyébként bonyolult megnyomni a build gombot egy másik IDE-ben


    Hát ha neked olyan a projekted, hogy minden architektúrán csak egy rebuild kell neki, és minden megy egyből, akkor gratulálok. (Kivéve nyilván a "Hello, world" szintű programokat.) Elvben tényleg elég egy rebuild, de a gyakorlatban nem mindenhol ugyanaz a short/int/long hossza, van ahol signed a char típus, van ahol unsigned, és persze a standard liben kívüli dolgokat minden platformon másképp kell használni. Ezek ellen mind lehet védekezni, de nagy odafigyelést illetve tesztelést igényel.

    Javában az int mindig 32 bites és pont. Ha túl is csordul a hibás kódom miatt, legalább mindenhol pont ugyanúgy fog túlcsordulni. Ha én letesztelem a windowsos PC-men, és nem találok benne hibát, akkor nagy biztonsággal jól fog menni Macen és linuxos PC-n is. Meg mosógépen is, ha valaki arra ír JVM-et. A gyakorlatban ez sokkal inkább hordozható, mivel igazából egy architektúrára kell csak figyelni, a Java virtuális gép architektúrájára.
    Mutasd a teljes hozzászólást!
  • Jól értem, hogy egyik nyelvet sem ismered, és azon gondolkozol, hogy elkezdd megtanulni az egyiket, hogy mondjuk 3 év múlva megpróbálj állást találni ezen a területen?

    Sok sikert!
    A Java nem vészesen lassú, ha valami lassú az sokszor a programozó hibája. Illetve a sebesség kritikus programrészt meg lehet írni más nyelven és azt meghívni Java programból. Van olyan, amire tényleg jobb egy gyors nyelv. Bár ahogy gyorsjulnak a gépek, így ez a hátrány egyre kissebb lesz.

    Esetleg nem haszontalan, ha több nyelvet is ismersz valamennyire. De ha nem akarsz időt pazarolni 2-3 másik nyelvre, akkor szerintem tökéletesen elegendő, ha a Java nyelvet tanulod meg (de azt nagyon).
    Mutasd a teljes hozzászólást!
  • Kisebb plusszmunka portolni egy JVM-et (vagy egy mono-t) egy új platformra mint az összes létező programot átfordítani.

    Ráadásul, ezt még akkor is a hajadra kenheted. Mert hiába van neked C++-os forráskódod, ha azok a könyvtárak amikre a programodat építed (mondjuk egy Qt vagy egy MFC vagy egy wxWidgets) nem elérhető az adott platformra. És a C++-szal pont ez szokott lenni a probléma.

    Másrészt pedig a java és a C# egy bizonyos dologra való, a C++ pedig alapvetően más jellegű dolgokra. Az egyikben ügyviteli szoftvert írsz, vagy komolyabb webes programot, a másikban drivert, esetleg játékot, vagy más hardverközeli dolgot.

    Az a 10-15% sebességkülönbség amivel a java lassabb mint a C++ pont azokat a biztonsági megoldásokat jelenti ami miatt a programod nem áll fejre ha te elszúrtál valamit. Ami mondjuk egy napi pár tízmillió forintot megmozgató weblapnál esetleg azért szempont lehet. Nem véletlenül szeretik Pl. a bankok a Javát és nem a C++-t.
    Mutasd a teljes hozzászólást!
  • Jó, meg lettem győzve. Már írom is a cuccost mondjuk Bada-ra. Ja, hopp azon nincs is se JVM, se BDM, se semmi, csak C++ compiler van hozzá. Akkor mégse platformfüggetlen az a Java. Egyébként bonyolult megnyomni a build gombot egy másik IDE-ben, tényleg nagy obb pluszmunka, mint az egész engine-t átírni Java-ról C++ ra.
    Mutasd a teljes hozzászólást!
  • Az Android egy külön kategória. Az ugyanis a Dalvik VM-re épül, ami nem kompatibilis a JVM-mel. Java nyelven programozhatsz rá és az osztálykönyvtár terén is elég nagy az átfedés, viszont a futtatható állományok nem kompatibilisek (Dalvik Executable - .dex).

    Tehát az Android-os VM-et nem igazán lehet Java VM-nek nevezni.
    Mutasd a teljes hozzászólást!
  • Androidon volt jó kis mizéria a Java, pontosabban a JVM miatt.


    Androidon nincs JVM, androidon Dalvik van, melynek nem celja 100%-ban kompatibilisnek lenni a JVM-el!

    C++ ban meg nemhogy minimális az esély, hanem gyakorlatilag ez az egyetlen normális módja a platformfüggetlen rendszernek.


    A magas szintu programozasi nyelvek elvileg platformfuggetlenek forraskod szintjen assemblyhez kepest. A Java forditott bytekod viszont a JVM-en fut, ha helyesen van implementalva, nem fugg az alatta levo platformtol.
    Mutasd a teljes hozzászólást!
  • Androidnak semmi köze a Javahoz, hiába próbálják az embernek bemagyarázni. Eleve nem jvm fut rajta, hanem dalvik vm. Ez olyan, mint amikor évekkel ezelőtt az emberek keverték a C-t meg a C#-pot. A normális jvm-ek minden platformon ugyanúgy futtatják a bájtkódot, kivéve ha teleszemetelték natív hívásokkal.
    C++ meg kb a legtávolabb áll a platformfüggetlensétől.
    Mutasd a teljes hozzászólást!
  • Nem hiszem, hogy furcsán, csak más szempontok szerint. Androidon volt jó kis mizéria a Java, pontosabban a JVM miatt. Különböző telefonokon egész másként futtata a másik JVM ugyanazt a kódot. Én ezt nem nevezném platform függetlenségnek. C++ ban meg nemhogy minimális az esély, hanem gyakorlatilag ez az egyetlen normális módja a platformfüggetlen rendszernek. Néhány modult át kell írni, de legalább van esély átírni. Java-ban mit csinálsz másik platformon a byte kódoddal, hogy jó legyen, ha esetleg az adott JVM nem ugyanazt csinálja? Semmit nem tudsz csinálni.

    De .NET-nél is ugyanaz van. xboxon ugyanaz a kód teljesen mást csinál, mint winen. És mit gondolsz erre mi volt az ellenszer? Az, hogy devkitet is kell használni, akkor meg már...
    Mutasd a teljes hozzászólást!
  • Kb. így lehet mondani viszonylag szakszerűen:
    A Java nyelvű programokat a JAva fordító Java byte-kódra fordítja. (Ma már sok olyan nyelv van a JAva-n kívül is, amelyhez ltezik Java bytekódra fordító!) A JAva byte kód egy kellemes kis viszonylag egyszerű stack orientált alacsonyszintű, gépikódhoz hasonló nyelv.
    A Java bytekódot a JVM (Java Virtual Machine) futtatja.
    Az ősidőkben (a huszadik században) ez a futtatás sima interpretálás volt. Ekkorról származhat a Java lesújtó sebességéről szóló információd. Ma már, a huszonegyedik században JIT technológiával futtatja a JVM a Java bytekódot. JIT = Just in Time compilation, vagyis on the fly lefordul a byte kód egy-egy részlete natív gépikódra. Így a futtatás tipikusan 20-30%- al lassabb mint egy hasonló C++ program esetében, de ez erősen függ az egyén programozási stílusától is. Amiért egyáltalán van ez a 20-30% romlás az tipikusan főleg a range checking tömbindexelésnél, és az automatikus szemétgyűjtés. Vannak dolgok, amik gyakorlatilag pontosan ugyanolyan gyorsak, mint C++-ban, pl. a sima számítások.

    2010-et írunk, ma már nem hogy a Java bytekód de már (részben) a Javascript is JIT-elt (ami azért sokkal kevésbé triviális egy Javascript szinten dinamikus nyelv esetén)
    Mutasd a teljes hozzászólást!
  • Furcsán értelmezed a platformfüggetlenséget. Egy lefordított java program bárhol fut ahol van jre. Egy lefordított c++ program csak azon a platformon fut amire fordították / kompatibilis azzal.

    Ugyan azt a java programot tudom futtatni, linuxon, unixon, windowson, solarison, stb.

    De egy C++ról fordított binárist nem fogod tudni használni avr-en, x86-on meg pic-en.

    Nekem legalábbis ezt jelenti a platform függetlenség.
    Persze az igaz hogy van rá minimális esély hogy ugyan azt a c++ kódot lefordítsd több platfomra. (különböző fordítókkal)
    Mutasd a teljes hozzászólást!
  • Akkor hogyan mondják szaknyelven azt, hogy nem közvetlen natív kódra fordít, hanem ilyen köztes kódra, amit aztán az adott gép, amin futtatják lefordít magának?
    Mutasd a teljes hozzászólást!
  • Valamennyit a JIT akkor is lassít, mivel futás közben hibákat ellenőriz, range checking stb. Tehát ha teljesen ugyanolyan lene a kód akkor azért lasabb lenne, de nem sokkal. De a Java és C++ között egyátalán nem a sebesség, hanem a platformfüggetlenség a lényeg. Az, hogy pl xbox-ra nem lehet Java programot írni még akkor se, ha esetleg egy Arcade játék optimálisan futna rajta.
    Mutasd a teljes hozzászólást!
  • 20-szor lassabb mint a C


    Ez hülyeség. (a mondat első fele szintén)
    Olyan nincs hogy egy platform x-szer gyorsabb vagy lassabb.
    Sok dologtól függ, pl magától a programtól + attól hogyan használják.
    Mutasd a teljes hozzászólást!
  • Inerpreter az c64-en volt, tudtommal a java sose volt interpreteres, jelenleg meg JIT-es. 20* különbség az sok lesz, inkább 20%. Teljesen más célra használják a kettőt. A C++ valódi platformfüggetlen, konzolon is működik mindenen, a Java meg csak 1-2 platformon. Az magában, hogy nyelvet simersz semmit nem jelent, inkább az adott terület ismerete a lényeg pl.: 3D grafika, vagy adatbázis kezelés stb. Az már zserintem teljesen részletkérdés, hogy egy java forrást fordítasz le futtatható programmá, vagy C++ t. Ha maga az API C++ t használ akkor fölösleges külön kerülővel Java-zni. Az a legkevesebb probléma, hogy egy másik szintaxisban írod a programot.
    Mutasd a teljes hozzászólást!
  • A Java-nak az a tulajdonsága, hogy le lehet fordítani közvetlen gépi kóddá is, alkalmassá teszi e arra, hogy olyan helyeken használjam, ahol a gyorsaság is szempont?

    A Java interpreteres használat esetén tudtommal 20-szor lassabb mint a C. A munkaerő piacon azt látom, hogy azzal érek sokat, ha EGY nyelvet NAGYON JÓL tudok, és nem azzal, hogy többet, de kevésbé. Java és C++ között hezitálok, tetszőleges álláshirdető oldalon 1.5-2 - szer annyi munkahely van Java-ra mint C++-ra. Tetszik az is, hogy az interpreteres tulajdonsága miatt platformfüggetlen alkalmazásokat lehet írni. Az , hogy appleteket lehet vele írni weboldalakra szintén tetszik. Viszont időnként tényleg szükség lehet olyan programok írására, aminek nem kell platform függetlennek lennie, de gyorsnak kell lennie. Alkalmas-e erre a Java?
    Mutasd a teljes hozzászólást!
abcd