Informatika és tudomány

Gyurkity Péter

A Sun a Java gyorsításán dolgozik

A Sun Microsystems külön projektet indított a Java alkalmazások memóriakezelésének, valamint a több alkalmazás egyidejű futtatásakor fellépő sebességbeli problémák javítására.

A Multi-Tasking Virtual Machine (MVM) prototípusát a Sun barcelonai laboratóriumában fejlesztik, és a vállalat honlapjának tanúsága szerint az új futtatókörnyezet elsődleges feladata a több Java alkalmazás futtatása körüli gondok enyhítése. A szakemberek szerint az MVM - amely a Java HotSpot Virtual Machine, valamint annak kliens fordítóján alapul - a több alkalmazás egyidejű futtatása révén növeli a Java skálázhatóságát, és csökkentheti a memóriaigényt. Példa erre Matthew Schmidt kijelentése, aki Java fejlesztőként a JavaLobby felhasználói közösség alelnöki posztját tölti be.

"Úgy vélem, az MVM megoldást nyújthat a Java egyik legnagyobb problémájára, amit a különösen nagy memóriaigény jelent több alkalmazás egyidejű futtatásánál" - jelentette ki Schmidt, összegezve az új fejlesztéssel kapcsolatos elvárásokat. Elmondása szerint a Java alkalmazások méretükhöz képest sok memóriát foglalnak le, és a probléma több alkalmazás egyidejű futtatásának esetében jóval nagyobb kellemetlenséget jelent.

A Sun fejlesztőcsapata időközben nyilvánosságra hozta a legfontosabb újítások egyikét. Ezek szerint az MVM lehetővé tenné, hogy a különböző Java alkalmazások egy virtuális gépen belül fussanak le - jelenleg ugyanis minden egyes alkalmazás saját virtuális gépet (Java Virtual Machine, JVM) igényel a futtatáshoz. "Az MVM egy operációs rendszerhez hasonlóan működik: egyidejűleg több alkalmazást is elindíthatunk, amelyek megosztoznak az erőforrásokon" - jelentette ki Schmidt.

Az új fejlesztés nagyobb skálázhatóság és kedvezőbb sebesség érdekében a J2EE 1.3.1-es verziójához igazodik - a Java 2 Platform Standard Edition egyes vélemények szerint nem lenne a legjobb választás, a vállalat azonban még nem hozta meg a végső döntést.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • alt3r3g0 #67
    Ne haragudj, de a szakmai vita érveket szokott jelenteni, nem üres kijelentéseket!
  • Hierogli #66
    "Persze a linux kernel c-ben írása mellett ez bőven elég érv!"

    Termeszetesen performance okokbol kifolyolag irjak a kernelt C-ben. Ez igy van a Windowsnal is. Pl. egy O(1) utemezot hatkeonyabb C-ben, mint C++-ban irni.
  • alt3r3g0 #65
    Na ebben nagyjából egyet értünk, kivéve a memória használot, bár meg kell jegyeznem korábban a sebességet hangsúlyoztad! ;-) Mivel foglal több memóriát egy c++ kód? Virtuális függvényeket tartalmazó objektumonként egy pointernyivel? Vagy mire gondolsz? Nem fogalmazol túl konkrétan... Jobb hordozhatóság miatt, egzotikus platformok bugos, rosszul optimalizáló fordítóin kívül én nem igazán tudok érvet a c mellett a c++ ellenében. Persze a linux kernel c-ben írása mellett ez bőven elég érv!
  • BlackRose #64
    Nem soroltam a C++ egy kategóriába a .NET nyelvekkel. A C++ az mint te is tudod native kódot eredményez (kivéve a .NET managed C++ át), és álltalában 20% vagy attól is gyorsabban fut a .NET féle kódtol. Csak azt akartam kihangsúlyozni, hogy a C++ már nincs annyira gépközelben mint a C, vagyis itt nem annyira sebesség gondok voltak a fejemben, mert C++ ban lehet irni C gyorsaságú kódot, viszont a C++ kód alapjában sokkal több darabot szakít le a gépből, gondolok itt mindenek előtt a memoriára stb. Persze C++ ban esetleg tisztább kódot irnának és jobban kezelhetőt, de szerintem egy OS kernelnek ez nem az elsőszámu prioritása. Az én "anyanyelvem" a C és a C++ meg a C# egyaránt és ez miatt egyiket sem részesíteném előnyben, de mindenesetre tudom, hogy mikor melyiket használnám.

    És persze, hogy lehet OS-t irni Javaban is, de a kérdés, hogy megéri e?
    Válasz 'alt3r3g0' üzenetére (#61)
    Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise
    Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
  • alt3r3g0 #63
    Nem írtál konkrétumokat, így vegyük sorra:

    member függvény hívások: ez csak egyszerű szintaktikai különbség, ha c++-ben ezt irod:

    object.function();

    a hívás assembly-ben már ugyanaz, mintha c-ben ezt irnád:

    function(Object* this);

    virtuális függvények:

    Ennek mint írtam van kis overheadje, de nem igazán létezik effektívebb módszer, kivéve speciális esetekben, nagyjából így működik:

    ugye egy class ami tartalmaz virtuális függvényt annak van egy utolsó nem látható membere, egy pointer a virtuális függvényeinek címét tartalmazó táblára. Tehat egy kétszeres indirekción keresztül (csak memóriaolvasás) történik, az nem egy vészes dolog. Egy hagyományos - tehát nem inlineolt függvényhez képest - a cache találat a leglényegesebb tényező, mind code, mind adat cache részéről. Magyarán, ha egy függvény nem inlineolt, és az ugrótábla benne van az adat cache-ben, akkor nagyon minimális a plusz művelet amit igényel, ha érdekel azt is kirészletezhetem, hogy milyen alternatíváid lehetnének, de egy másik hozzászólásban, így is túl hosszú leszek...

    template-ek: ezekkel egy függvény-t class-t tudsz sokféle típusra legyártani, de ez sebességben nem jelent overhead-et, mivel külön külön legyártja őket az összes használt típusra, egy egyszerű nem túl gyakorlatias példa:

    template <class T>
    void SetOne(T &Val)
    {
    Val= 1;
    }

    függvény esetén ha használod int-el és float-al, akkor legyártódik 2 féle verzió, így pont ugyanaz, mintha te írtad volna meg őket mindkét típusra. Természetesen ezt bármly normális fordító ki-inlineolja, és gépi kódban már nem lesz semmiféle függvényhívásod, egyszerűen egy memóriacímbe, vagy regiszterbe tölti direkt módon az int vagy float 1-et.
  • Hierogli #62
    "tankönyvszagú kijelentésekkel szeretnék vitába szállni."

    Hat hajra.
  • alt3r3g0 #61
    Az utolsó mondatod nem tudom, nekem szól-e, ha igen félre vagyok értve...
    A miben írj oprendzsert témához én nem szóltam hozzá, csupán idéztem BlackRose-tól, és engem a mondatának az a része érdekelt, hogy sebesség terén a c++-t egy kategóriába sorolta a .NET alapú managed nyelvekkel. Csupán az "az objektum orientalt elvekhez kapcsolodo absztrakt nyelvi elemek valoban extra overheaddel jarnak" tankönyvszagú kijelentésekkel szeretnék vitába szállni.
  • alt3r3g0 #60
    Jogos, de mivel futási időben történik, az optimalizálása szánt idő erőssen korlátozott, ezért nem hiszem, hogy beérik, vagy lehagynák a natív gépi kódot fordító nyelveket. Persze java-nál ott vannak még más sebességet visszafogó tényezők is, mint automatikus tömb túlcímzés vizsgálat, vagy, hogy minden member függvény virtuális. Profile alapján optimalizálást egyébként a mai fejlett c++ fordítók is tudnak, az új intel compiller, ill a vc 2005 már támogatja.
  • dshk #59
    a java virtális gép miatt önmagában nem kell lassabban futnia egy kódnak, sőt futhat gyorsabban is: a vm ugyanúgy gépi kódra fordít, csak futásidőben, ez viszont azt is jelenti, hogy futásidejű információja birtokában optimalizálhat. Egy statikus compilernek nem állnak rendelkezésre ezek az információk.

    A mobiltelefonok java futtatójával az a baj, hogy még nagyon primitívek, többnyire egyszerűen interpreter módban működnek, természetes hogy lassúak. Sokat azért nem kell várni, hogy az asztali gépeken alkalmazott java futtatók techinkái leszivárogjanak a mobiltelefonok szintjére.
  • irkab1rka #58
    hogy pontosítsak: nem, nem keverem a VMS-t és a clustert (ég és föld), csak fáradt vagyok átvezetéseket írni az egyes mondatok között :)
    Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
További bejegyzések a fórumban...