Solaris driverek írása Java-ban

Solaris, OpenSolaris, Illumos

"A C programozási nyelv rugalmas és hatékony szoftverek írását teszi lehetővé. A C-t hagyományosan felhasználják rendszer-szoftverek - beleértve operációs rendszer kernelek - írására. Azonban, mivel a C hiányát szenvedi a típus és memória biztonságnak, továbbá manuális memóriakezeléssel terhes, ezért hibára hajlamos, nem biztonságos, és a vele készített szoftverek gyakran sebezhetőek olyan biztonsági támadások által, mint például a puffer túlcsordításos támadások.

Ezzel szemben a Java programozási nyelv az elmúlt évtizedben népszerű, mert típus és memória biztos, automatikus memóriakezeléssel rendelkezik, gazdag szabványos lib-ekben, objektum-orientált, portolható, és számos más szolgáltatással rendelkezik. Ennek ellenére ritkán használják rendszer-szoftver készítésre; a Java Virtual Machnine általában felhasználói programként fut, Java bytecode-ba fordított alkalmazásokat értelmez vagy fordít dinamikusan."

Hiroshi Yamauchi és Mario Wolczko írásában a Java virtuális gép egy olyan kísérleti módosítását mutatja be, amely a Solaris operációs rendszer kernelén belül fut. Az implementáció úgy készült, hogy beleportoltak a Solaris kernelbe egy már meglevő, kis méretű, portolható JVM-et, a Squawk-ot. A rendszerhez készített első alkalmazásuk lehetővé teszi, hogy eszközmeghajtó-programokat lehessen írni Java-ban. Az írásban bemutatják, hogy hogyan lehet egy egyszerű, C-ben írt driver-t (RAM disk driver) Java-ra portolni. Továbbá bemutatják a Java driver tulajdonságait, és az eszközmeghajtó-program csatolófelületüket.

A dokumentum itt.

( trey | 2006. 10. 21., szo – 09:03 )

Lehet, hogy ez a jövő?

--
trey @ gépház

Igen, es a perl sokkal gyorsabb lesz, mint egy olyan nyelv, ami mar a futtataskor bytecode interpretert hasznal. A java amugy is lassu, pythont kell hasznalni, ESR is megmondta:). Az emberekben nagyon megragadt az, hogy 1998ban a netscape nagyon lassan mutatta meg a java appleteket. En sem vagyok nagy java fan, de igy sokkal tobb solarisos driver lesz, mert megkonnyiti az olyan driverek fejleszteset, aminel nem kritikus a teljesitmeny (pl. egy soros portra csatlakozo infra vevo, de meg millio ilyen van).

Kapaszkodj meg: a perl is azt használ. Sőt, a perl6-osban külön is válik maga a nyelv, és a virtuális gépe, ez utóbbi a Parrot névre hallgat. Egészen zseniális emberek tervezik, és elég jól halad: a tavalyi perl6 konferencián egy Parrot assemblyben írt (karakteres) bemutatóprogrammal vetítettek a Parrot-ról, nem kis sikert aratva.

Egyébként, igen: perl-ben is lehetne. Már évek óta mondom, komolyan :)

"Szerző: trey
Dátum: szo, 2006-10-21 12:27

Ami kb. akkor lesz, amikor a Mac OS X (el)ismert, és elterjedt desktop operációs rendszer lesz :))"

Na!
Ezt vártam :-{)
És kb. egybe fog esni a "biztonságos windows" fogalmával.

Akkor majd a Linuxos/BSD-s gépek elé windows tűzfalgépet fognak tenni:)

Bár csalinak ma is jó.

( Exit | 2006. 10. 21., szo – 09:18 )

Az ötlet mondjuk nem új, hiszen a Jnode-ban (sok minden más mellett) a drivereket is Java-ban fejlesztik, ahogy az felépítésén is látszik.

Mindenesetre izgalmasan hangzik, hogy egy viszonylag népszerű operációs rendszeren is próbálkoznak vele.

( mpathy | 2006. 10. 21., szo – 09:35 )

Ez kész.

Tán némi teljesítményoldali okai is vannak annak, hogy a c terjedt el, mint olyan magas szintű nyelv ami alkalmas operációs rendszerek megvalósítására. Ok, tudom, lehet venni még nagyobb vasat...

Azért azóta sokat fejlődtek a fordítóprogramok is. 10 éve még nagyon kevesen álltak volna neki numerikus számításokat C++-ban programozni, mert C-ben vagy Fortranban sokkal gyorsabban lefutott. Ma már megéri C++-ban írni ilyesmit, mert nem sokkal lassabb, mint C-ben, viszont sokkal áttekinthetőbb. (Persze, nem tudom, a Java esetében mi a helyzet. Bár számításokat ma már Java-ban is írnak.)
A másik, hogy a C azért nem egy magasszintű programozási nyelv, sokkal gépközelibb annál.
(Ezt most attól függetlenül írom, hogy nekem is a C az egyik kedvencem, és kicsi, rövid, de gyorsnak szánt dologokat én is C-ben írok. De nem lepne meg, ha egy olyan oprendszer, amiben legalábbis a bonyolultabb részeket egy objektumorientált nyelvben valósítják meg, a végén stabilabb, átgondoltabb lenne.)

(Persze, nem tudom, a Java esetében mi a helyzet. Bár számításokat ma már Java-ban is írnak.)
A java esetében az a helyzet, hogy számítási teljesítényben az optimalizálás nélkül fordított C programokat kb 3-4x-esen megverei, -O2 vel fordított C programokkal szemben kicsi, kb 10%-os hátrányban van. Metódushívás, attribútumlekérdezés nagyjából ugyanannyi idő alatt fut le java alatt, mint egy c programban egy függvényhívás illetve egy struct adattagjának elérése. Az egyetlen dolog, amiben a java rémesen lassú (kb 10x-esen) a c-hez képest az az új objektum létrehozása vs. új struct lefoglalása malloc-kal. De pl az új 1.5-ös java vm már csinál object pooling-ot, ami azt jelenti, hogy ha már korábban létrehozott és törölt egy bizonyos típusú objektumot akkor egy későbbi ugyanolyan típusú új objektumnál újrahasználja a memóriaképet, ha az még nem íródott felül. Aztán van olyan is, hogy a metóduson belüli lokális élettartamú objektumokat stack-en hozza létre, ami kb megfelel a c-ben a sima függvényen belüli lokális változóknak. Ezek bizonyos körülmények között elég nagyot tudnak gyorsítani.
Igazából a javas alkalmazások nem azért lassúak, mert a java lassú, hanem azért mert rettenetesen bloatware-ek. A programokat többnyire egy valamilyen framework api-ját felhasználva írják, és nem ritka, hogy ez a framework egy másik frameworkre van építve, ami szintén egy újabb framework apijára támaszkodik. Gyakori, hogy 3-4 ilyen egymást elfedő rétegen is keresztül megy egy hívás és az egyes adapter osztályok mindig átcsomagolják az adatot, mert az egyik metódus Array-t vár, a másik List-et ad vissza stb. Az is tetézi a problémát, hogy az 1.5-ös java api-ja már template-tel megadott típusos kollekciókat használ, de sok 3rd party api-t még nem frissítették erre. Továbbá jellemző még, hogy sok helyen teljesen suta, oda nem illő adatszerkezetet használnak (pl Vector a HashTable helyett, stb), amiben pont az a művelet lassú, amit leggyakrabban használni kell rajta. Ami még rosszabb, az api-k miatt az ember néha maga is rá van kényszerülve ilyen disznóságokra. Persze tisztelet a kivételnek...
Tehát az, hogy a solaris java-s driverei mennyire lesznek sikeresek az teljesen azon múlik, hogy mennyire jól átgondolt a kernel java-s api-ja, illetve a ráépített modulok api-jai mennyire lesznek egységesek. Gondolom a sun-nál egy kicsit több gondot fordítanak erre, mint a hárombetűsnél...
---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.

Felhasznaloi oldalrol az a tapasztalatom, hogy a javas programok lassusagat elsosorban nem a processzorterheles okozza, hanem a memoriahsznalat, es az ebbol adodo folyamatos swappeles. Ezen valoszinuleg az object pooling nem segit.

En egyebkent keszseggel elfogadom, hogy lehet javaban is gyors programot irni, csak nem ez a gyakorlat. Ez persze egybevag azzal, amit irtal, de keves a boldogsaghoz.

Magam reszerol erdeklodessel szemlelem a java ternyereset, mert jo kis nyelvnek tunik, de az egesz VM koruli szenvedes kicsit ellentmondasossa teszi. En ugy erzem, hogy a java nem tokeletes, de egyelore egy csomo feladatra nincs jobb. A C++-nak megvannak a maga nyugei, a C#-ot nem biztos, hogy eroltetni kellene, es akkor mar sokkal inkabb java, a D meg meg csak most erik.

Nem szoktam joslatokba bocsatkozni, de kozel van a kiadas, en pedig mar jo ideje hasznalom. Az "erik"-et en sokkal inkabb ugy ertem, hogy meg nem terjedt el, es ebben tenyleg lehet komoly akadaly, hogy a Sunnak es Microsoftnak lenyegesen tobb penze van marketingre, es a donteshozokat meggyozni.

Ugyanakkor elterjedt a Python is, a Perl is, stb, tehat a dolog azert keteselyes.

Szemely szerint jobbnak tartom, es jobban szeretem, mint a Javat, tetszik, hogy ugyanazt a forrast fordithatom, ill. interpretalhatom, mindent hoz szamomra, ami jo a C-ben, a C++-ban, vagy akar a Javaban, es nem tudok komoly hatranyarol vagy hianyossagarol, az egyelore szegenyes library kinalatot kiveve, de ez nem a nyelv hibaja. Nyilvan nem tokeletes, meg azert van egy kis csiszolgatas vele, de a Java sem a jelenlegi formajaban jelent meg eredetileg.

Ja es a Java sem 2 honap alatt sztuletett. :-) De ez nem vesz el semmit a dolog ertekebol, remelem. ;-)

Én négy éve néztem a D-t, használtam is egy kicsit, akkoriban C++ template-ek meg egyebek alternatívájaként. Aztán rájöttem, hogy library nélkül nem ér semmit egy nyelv, ahogyan erre rájött 11 éve a Sun és 5-6 éve a Microsoft is. Nem véletlen, hogy mind a Java, mind a .NET _iszonyatosan_nagy_ osztálykönyvtárral jön. A nyelv mindkét esetben csak egy kis apróság a libekhez képest, és libek nélkül marketinget is tehetnek mögé, nem lenne semmi sem.

Éppen ezért nem értem ezt a mindegymidecsakazértsem-java hype-ot. Itt van egy elég kiforrott eszköz, versenyképes (szinte egyenértékű) a C++ sebességével (C-ben ma már nem csinálnak _nagy_ programokat), az eszköztámogatottsága miatt olcsóbb rá a fejlesztés (kevesebb idő, kevesebb hiba, biztonságosabb kód), erre jönnek a csináltunkvalamijótamimármadjnemjava eszközök, és az emberek azt hiszik, hogy az nekik jobb lesz. Sokan azt hiszik, hogy a szintaktika minden. Aztán mikor bejön az XA tranzakció kezelésének kérdése, akkor csak néznek, hogy mi fán terem :)

Ugyanúgy implementálnak egy virtuális gépet. Nade milyent? Amelyik évente változni fog? Vagy visszafele nem lesz kompatibilis? Vagy csak egy "gyártó" szállítja? Ahelyett hogy megnéznék a harmony-t. Vagy ahelyett, hogy megnéznék a Java forráskódját, és átgondolják, hogy ez nem is olyan gyorsan létrejövő feladat.

Amíg nincs ezek mögött a kezdeményezések mögött egy vállalatóriás, amelyik megtámogatja a projektet pénzzel, addig ezek reménytelen dolgok. Ha meg lesz, akkor annak lesz annyi esze, hogy valamelyik kész rendszer mögé áll. Mint az ipar nagy része a Java mögé, vagy mint egy akkora óriás mint a Microsoft külön utakon. Jelenleg erre legfeljebb a google képes, de ő már részt vesz a Java konzorciumban.

A Java ellen én egyetlen ellenérvet fogadok el: nagy. De ha egyszer megtanulja valaki, akkor bármit el tud vele érni, még kernel-drivert is írhat ;)

Szinte mindenben egyetertunk, amit leirtal, ugynakkor en bizom abban, hogy ugy mint a Pythonhoz, D-hez is letrejohet tisztesseges meretu library gyujtemeny, es a tovabbra is fenntartom, hogy a javaval nem elmeleti, hanem gyakorlati gondok vannak. Tehat megirhato lenne benne sokminden jol, es hatekonyan, de nem ez a tapasztalat. (Pl. MATLAB, MKS).

A Javat, mint nyelvet nagyon jonak tartom, es az elterjedese nagy lepes a minosegi szoftverek iranyaba, de a VM miatt sajnos a tetulassu szoftverek iranyaba is, megha ez utobbi nem is lenne szuksegszeru, vagy torvenyszeru.

Ez azért túlzás. JEdit-et használok rendszeresen néhány pluginnal, néha iszonyatosan be tud lassulni ha a gui-n módosítok, pl. ha az ablak méretét módosítom, vagy nagyobbra veszek egy panelt. Az indítása is lassú, nem véletlenül van hozzá memóriában csücsülő "szerver".

Persze szövegszerkesztés közben nem annyira zavaró a lassú gui, de egy "gyors" programról más elképzeléseim vannak.

Amiért mégis szeretem, az a képességeinek sokrétűsége. De semmi esetre sem a sebessége :)

Igen, ez sajnos a swing hülyesége, minden pixelnyi húzáskor lefut a layouter kód. A másik "kedvencem" a hülyén megcsinált model-view-controller kód, amikor pl egy fa nézetet teljes mélységében felépít, pedig lusta felépítés kellene, hogy csak az legyen lepéldányosítva, ami ténylegesen ki van nyitva. Továbbá azzal is lehet nagyot lassítani, ha minden módosuláskor teljes modell újraépítést csinál, ahelyett, hogy csak a változást vinné át. Persze ez utóbbit sokkal több meló lekódolni...
---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.

Amiért mégis szeretem, az a képességeinek sokrétűsége. De semmi esetre sem a sebessége :)
Ez jellemzo a magasszintu nyelvekre. Konnyen lehet sokretu programot irni, de lassabb lesz... (De legalabb elkeszul belathato idon belul.)
Ami okokat irtatok a lassusagra, azok igazak, es folyamatosan javitjak is (amit lehet).

Igazából a javas alkalmazások nem azért lassúak, mert a java lassú, hanem azért mert rettenetesen bloatware-ek. A programokat többnyire egy valamilyen framework api-ját felhasználva írják, és nem ritka, hogy ez a framework egy másik frameworkre van építve, ami szintén egy újabb framework apijára támaszkodik. Gyakori, hogy 3-4 ilyen egymást elfedő rétegen is keresztül megy egy hívás és az egyes adapter osztályok mindig átcsomagolják az adatot, mert az egyik metódus Array-t vár, a másik List-et ad vissza stb.
Pl. ezt a problemat hogy javitanatok ki?
Ugye ha nem epulenenek egymasra, akkor megint drasztikuan none a fejlestesi ido, amit ma nem igazan fizet meg senki.
Az Array, List problemak tenyleg csokkenthetoek lennenek, de hat nem vagyunk tokeletesek. Sok javas programozo ugy valaszt adatszerkezetet, hogy a metodusait kozvetlenul fel tudja hasznalni, es eszebe sem jut, hogy a hatterben konverzio van... Ez reszben ugye a tudatlansag miatt van, de aki netan ismeri, az sem biztos, hogy odafigyel, mert a hatarido az hatarido, es a konnyebbet valasztja.

Azt kell megerteni, hogy ma mar keptelenseg egy nagyobb programnal minden reszletet "tokeletesre" megcsinalni. Sokkal fontosabb, hogy a programok sokat tudjanak, es gyorsan elkeszuljenek... Persze minden programnal meghuznak egy hatart, ami az egyik felhasznalonak jo, a masiknak nem.

Erre jo pelda a Debian. Otthoni hasznalatra inkabb a testing, unstable kerul hasznalatra, mert tobb uj dolog van benne... Azaz valamit valamiert.

Most elindítottam 10+ példányban a jedit 4.2-t, mindegyikben megnyílt az a 10 default doksi, amit legutoljára használtam. Elkezdtem őket huzogatni, és nálam nem lassú. Bizonyára amiatt van, hogy nálam van elég memória a swing memóriában tartására, mással nem tudom magyarázni a különbséget. Esetleg azzal, hogy a fejlesztés alatti újabb verziót használod, abban tényleg van valami szerver, nem is használta öt percnél tovább :)

A C++-nak megvannak a maga nyugei, a C#-ot nem biztos, hogy eroltetni kellene, es akkor mar sokkal inkabb java, a D meg meg csak most erik.

Azon kívül hogy gyakorlatilag semmi szakmai nincs ebben a mondatban, elmondanád, hogy mi a baj a C#-al? Ez a "nem biztos, hogy erőltetni kellene" valahogy nem kézzel fogható... :)

Igen nem irtam esszet a kerdesrol, tehat nincs benne semmi szakmai, pusztan a sajat velemenyemet suritettem egy mondatba.

C++:
a nyugok ismertek, eleg vaskos konyvek szulettek a arrol, hogy mikent is kellene a nyelv problemait megfelelo programozassal orvosolni

C#:
az a gondom vele, hogy egy olyan platform, ami arra lett kitalalva, hogy a Microsoft technologiakat egyesitse, es ennek kovetkezteben alapveto problemakat hordoz a portolhatosag tekinteteben, hiszen semelyik masik platformra nem lesz elerheto a .Net framework teljeserteku microsoftos implementacioja.

Tehat nem a nyelvvel van bajom, hanem a mogottes technolgianak a gyartohoz kotott sajatossagaival.

Ezert sokkal inkabb a Java, ami eleve egy kersztplatformos kornyezetnek lett kigondolva, es velemenyem szerint nem hordoz alapveto hatranyokat a C#-pal szemben.

Ne beszelj hulyeseget. A java minden fuggvenyhivasnal (kivetel static fuggveny) megkeresi az objektum virtualis fuggveny-tablajaban _nev szerint_ (ertsd strcmp vagy hash) a fuggvenyt, es aztan hivja meg. Mert ugye ami nem static, az virtualis. Ezzel szemben a C rogton belinkeli. Szoval ne hasonlits egy CALL x86 utasitast egy komoly virt. fv cim kereseshez - nagyon nem ugyanaz. Mellesleg vicces, hogy pont azt a teruletet hoztad fel peldakent, ahol a java egyertelmuen 1-2 nagysagrenddel lassabb, mint a C.

A java sose lesz olyan teljesitmenyu, mint amit c-ben meg tudsz csinalni, egesz egyszeruen azert, mert a dinamikus megoldas nem tudja felvenni a versenyt a statikussal. C-ben ugyanazt a memoriateruletet ezerszer ujrahasznalom, java-ban meg foglalhatok ujat (persze lehet trukkozni, de akkor meg mar inkabb csinald c-ben).

Amit irtal az api-krol, abban viszont melysegesen egyetertek veled - ez tenyleg nagy rakfeneje a java-nak sajnos.

Inkabb azt mondanam amugy, hogy azert lassubb _jelentosen_ a java, mert aki java-ban programozik, az foleg azert teszi, mert nem kell tokolni minden aprosaggal, mint a c-ben. Aztan persze hogy a kenyelmes kod lassubb is. Ha meg total performace optimalizaltan irna meg, akkor meg rondabb lenne, mint a c-s kod, meg lassubb is - hat nem teszi. Igazabol IMHO ez az oka annak, hogy a gyakorlatban sokkal lassubbak a java-s progik mint a c-sek.

Ez teljesen elkepzelheto. Akar csavarhuzoval is lehet szoget beutni kalapacs helyett. A kalapacs masra nagyon nem is jo, megis van nemely szakinal kalapacs.

1. A nagyteljesitmenyu szamitasok szempontjabol a Fortran/C/C++ is legalabb annyira hordozhato, mint a Java. Az ujraforditassal egyutt lehet elni es a keves fuggosege van a programoknal (azok is inkabb a szabvanyos konyvtarak fele).
2. Javaban sokkal nagyobb erofeszitest igenyel az optimalizacio, mint az alacsonyabb szintu nyelvekben, leven a JVM mukodese kevesbe atlathato es nehezen szamithato ki elore.
3. A Java alapvetesei kozott a szolgaltatas-teljesitmeny kozotti konfliktusokat tobbnyire a szolgaltatasok javara oldottak fel. Ez jo, mert igy lehet a programozok millioinak egy gazdag nyelvet adni. Viszont az a parezer programozo, aki a komprumusszummentesen szeretne minel jobb teljesitmenyu programot csinalni (mert ez az egyetlen komoly elvaras a szoftverevel szemben), az teljesen joggal erzi ugy, hogy a Java nem neki valo, ellenben jol elvan az assembly-tol c++-ig terjedo nyelvekkel.

1. Mit nevezünk nagyteljesítményű számításnak? Tiszta matematikai algoritmusok optimalizált bitvarázslását én sem Javaban írnám. De abban a környezetben, ahol eddig dolgoztam, ez még csak marginálisan sem jött elő.

2. A JVM működése teljesen jól átlátható, egy kicsit meg kell ismerni, hogy mi a szabvány rá, de azt hiszem a C++ mutatókat is meg kell tanulni, mielőtt használja valaki. A kiszámíthatóságról csak annyit, hogy a Sun már demózza és talán már árulja is a real-time java-t.

3. Szerintem meg nagyon sokminden elvárás van a szoftverrel szemben, a teljesítmény is fontos, de távolról sem a legfontosabb. Nézzük csak, talán sorrendben: fejlesztési költség (idő, fejlesztő ára), hibák száma (support költsége), bővítési lehetőségek (mennyi idő múlva kell az egészet újraírni, újabb sok pénzért), mennyire lesz egyszerű 5 év múlva fejlesztőt találni, aki még bele tud túrni a kódba, és csak mindezek után számít a teljesítmény. Legalábbis ez az én tapasztalatom.

Bár ennek a résznek nem néztem annyira utána, hogy pontosan mit is csinál, de a mérési eredmények azt mutatják, hogy egészen minimális eltérés van C-s és a Java-s függvényhívások ideje között. Nyilván a jit fordító egy csomó helyen észre tudja venni, hogy nincs szükség a dinamikus keresésre és amit lehet fordítási időben előre kiszámol. (A reflexiót ne keverjük ide, annál nyilván nem lehet optimalizálni, de valami hozzá hasonlót c-ben csak igen nagy többletmunkával lehet megvalósítani és kérdéses, hogy akkor mennyi marad a c-s megoldás előnye) Az objektumok pedig mindössze asszem 8 byte-al nagyobbak egy ugyanolyan adattagokat tartalmazó c struct-nál. Ebből az egyik nyilván a referencia számláló, a másik pedig a pointer a class-ot leíró objektumra. Tehát a classot a classloader egyszer tölti be, akkor kiszámolja a hash-et a függvényekhez és lerakja a táblába. A függvényt meghívó kódrészletben pedig a függvénynevekből a jit fordító kiszámolja a hash-et. így már szerencsés esetben egy db bitmaszkolás egy összeadás, egy indirekció és egy int compare megtalálja a függvénytörzset és már indulhat is a hívás. Ha nem ez az első hivatkozás az objektumra, akkor az objektumhoz tartozó class leíró ráadásul már a cache-ben figyel, mert minden hivatkozáskor úgyis szükség van rá. Valószinű egyébként, hogy a java többletmukájának a nagy része olyan, ami jól cache-elhető, ez pedig elfedi azt, hogy a vm többet dolgozik a natívan futó kódnál, mert mindkét program futási idejét a memóriára várakozás határozza meg, ami nagyjából egyforma mindkét esetben. Ezt alátámasztja az is, hogy azt tapasztaltam, hogy a nagy cache-el megáldott intel processzorok észrevehetően gyorsabbak java végrehajtásban a tipikusan kis L2 cache-el felszerelt athlon-okhoz képest.
Miért hoztam fel példákat az új objektum létrhozással kapcsolatban: mert ezek a technikák mind csökkentik a java lemaradást a c-hez képest. Pl az object pooling kapásból majdnem 2x gyorsít, így már csak kb 5x-ös a lemaradás.

A java sose lesz olyan teljesitmenyu, mint amit c-ben meg tudsz csinalni,
Kérdés, hogy érdekel-e ez valakit, ha mondjuk 10% alatti a lemaradás. (Jó talán még nem tartunk itt, de úgy veszem észre, hogy elég jól fejlődnek a vm-ek) Általános felhasználásban ennyi fel sem tünik, még number crunching alkalmazásoknál is határeset. Pl ASM optimalizációra 10% várható gyorsulás esetén még nem nagyon szoktak rámozdulni, csak ha nagyon triviális a feladat, vagy nagyon hard realtime rendszerekben, amikor éppen ennyivel lóg ki egy számítás a rendelkezésre álló időből.

Viszont pl C-ben viszonylag ritkán jut eszébe az embernek hash táblát vagy AVL-fát lekódolni kézzel, a glib2-ben találhatót használni meg elég nehézkes (a típus biztonság, void* rulez :) ). C++-ban ugyan van STL, amivel már viszonylag kényelmesen használhatók, de a template-eket meg elég gyéren optimalizálja gcc. Szóval a lényeg, hogy a kényelem miatt _elvileg_ a programozó a feladathoz alkalmasabb adatszerkezetet válaszhat, ami nagyságrendi gyorsulást eredményez a fapados c-s megoldáshoz képest. Tehát így a java-s megoldás gyorsabb is lehet. Más kérdés, hogy a gyakorlatban nem mindig van ennyi esze a programozóknak. Pedig a java-s profiling is egyszerűbb és így könnyebb megtalálni a feladatnak megfelelő adatszerkezetet. Csak a gyakorlat azt mutatja, hogy a programozók csesznek profiling-olni. Nyilván örülnek, hogy végre működik ami kell, azt máris vár rájuk a következő feladat.
---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.

( ProTech | 2006. 10. 21., szo – 10:25 )

En mindig ugy vagyok vele, hogy egy jo programozo tudja mikor melyik nyelvet kell hasznalnia.

Tipikusan oprendszer irasara nem jo a java. Ennek a hirnek kb. annyi a jelentosege mint a PHP-ban irt halozati retegnek.

En szeretem a javat, de tudni kell mikor hasznaljon az ember c-t, bash-t, perl-t, stb...

Nekem egyértelműnek tűnik a cél, ami pedig nem más, mint a linuxos user space fs megoldásé, csak itt általánosabban közelítik a dolgot.

A lényeg, hogy az éhező, kihasználatlan java-programozók nekiessenek drivert írni egy olyan nyelvben, amellyel produktívabbak tudnak lenni és kevesebb hibát tudnak véteni, mint a c-ben.

Nekem ne irjon olyan drivert, aki nem ismeri a csodas kfree() -t pl.

Egy drivernel, miert lenne jo mar OO? Az ős driver osztaly leszarmozattai lehetnenek a driverek es, hogy ugy "menyire szep nez ki a kod", rohely.

http://developer.gnome.org/doc/API/2.0/gobject/index.html
c -ben is lehet OO szemlelettel kodolni.

( DirtY_iCE | 2006. 10. 21., szo – 11:21 )

„Azonban, mivel a C hiányát szenvedi a típus és memória biztonságnak, továbbá manuális memóriakezeléssel terhes, ezért hibára hajlamos, nem biztonságos, és a vele készített szoftverek gyakran sebezhetőek olyan biztonsági támadások által, mint például a puffer túlcsordításos támadások.”

Driver javaban? Még arréb van április 1je.. szerintem aki ezt nem képes megírni c-ben, az inkább hagyja abba a programozást és keressen magának valami más elfoglaltságot... arról nem is beszélve hogy a javas cuccok sokkal lassabbak, mint amit c-ben írnak

.:Linux 4 eveR:. (most már ki merem írni, beee!)

Interpretalt byte code ugye?
Tehat lasabb.
Driver eseteben, ha 0.1% kal lenne lasabb es 0.1% kal fogna tobb memoriat java/JVM es 100 szor kevesebb kodsorbol alna, akkor is C -re szavaznek.

Ha veszunk egy utasitast pl. ertek adas (egy konstanst beteszunk pl. egy int -be) ami ~egy ora jel native, ha azt interpretaljuk, az hany orajel szerinted minimum?
Legalabb 2. Es legtobb driverben foleg 1 orajeles utasitasok vannk, ami interpretalva min. 2 -lesz. Egy 40+ orajeles utasitasnal lehet, hogy anyira nem szembetuno (float div).
Arrol nem is beszelve, hogy try,throw os hibakezelest, methous hivasokat is intrpretalni kell, ami nyilvan koltseges.

Ha csoda java -ban, hasznalsz ojjektumokat, az tobb memoriat eszik, mig C++ ban, egy nem virtualis osztaly objektumai anyit esznek, mint amenyi adat van bennuk, virtualis methodusos objektumok egy + mutatonyival hosszabbak. Java -ban minden ojektum tartalmaz virtualis methodust (Orokolve Objektol). A gc is biztosan hasznal nemi memoriat, plusz figyelni kell a referencia szamot... stb.

Java nem igazan ismeri az elofordito csodait. Ami miatt igen kenyelmetlen lehet a driver kodolas, vagy futasi idelyu dontesekre kesztetheti a programozot, meg tobb memoriat megeve.

Generikus programozas tekinteteben is, hagy maga utan nem kivanni valot. (Inakbb csak generikusnak csufolt.) (ami C -ben sincs, de sok # el kezdodo sor csodakra kepes)
De vegulis senki nem tiltja, hogy gcc eloforgatojan atkuldjuk a java kodot, es akkor mar van eloforditonk :)

Ketelkedem abban, hogy egy drivert java -ban kenyelmesebben lehetne irni.

EnhancedForStatement 1.5 javaban az tenyleg kenyelmes dolog.

Hi!

Nem tudom, hogy felvilagositott e mar valaki. De a JVM-ek manapsag mar nem kizarolagosan interpretaltan futtatnak, hanem van a az ugynevezett JIT (Just In Time compiler) ami native kodra forditja a cuccot es azt futtatja.
Olyan ez mint a Transmeta Crusoe code morphing technologiaja.

( rhapsodhy | 2006. 10. 21., szo – 14:20 )

Bar szeretem a java-t ettol kicsit megilyedtem, erdekes. Viszont teny, hogy baromi lassu. A fejlesztok szerint azonban ez a sebessegkulonbseg csokkenni fog, mert nincs optimalizalva a VM, meg ilyesmi. Meglatjuk, mi lesz belole.

"The Java version took 178 microseconds
and the C version took 63 microseconds. When a GC occurred during
a copy, the Java version took 230 microseconds. The Java version took
approximately 2.8 times and 3.8 times longer than the C version
without and with a GC, respectively. "

Ha 1.5 times ala viszik (interpretalt byte koddal) akkor megeszem a kalapom. :)

A pelda kod, hat nem tul "javas", nagyabol egy osztalyba zart C kodhoz hasonlitanam. Nem is hasznal tul sok semmit java standard konyvtaraibol.

Ennek a JVM -es driveresdinek anyi ertelme van, mint pl. backtracket implementalni bash szkriptekkel (pl. a helyett hogy Javaban vagy C/C++ -ban megirtak volna). Erdekes, de nincs kulonosebb jelentosege.

Lehet, hogy sosem lesz kozel olyan sebessegu egy javas driver, de azt se felejtsuk el, hogy
- egyre kevesebb a profi C programozo (sajat tapasztalat), kozben egyre tobb driverre van szukseg a sok termek/szabvany miatt
- egyre bonyolultabbak a driverek, azaz nol a fejlesztesi ido (pl. ipv4 -> ipv6)
- ...

Egyszeruen vannak olyan helyek ahol nem szamit, ha ketszer annyi ideig fut valami, ha a fejlesztesi/tesztelesi/modositasi/... ido a toredeke.
(A hibak nagy resze rossz memoria kezelesbol adodik! Elmeletileg ez megszunne. ...)
Azokon a helyeken, ahol sebessegre,... kell optimalizalni, feltehetoleg meg sokaig C-ben, asm-ben fogjak irni a drivereket.

Azon pedig nem csodalkozok, hogy az elso probalkozasok utan ekkora sebesseg kulonbseg van. De azon sem csodalkoznek, ha par even belul 1.5 times-en belul lenne.

2.0 times is lehetetlen kozelinek tartom, Hardveres gyorsitas nelkul. Most atfuttoam Java asm -et, nem csoda, hogy sparkon kicsit gyorsabb (Load & Strore RISC).
Nem tartom lehtetlennek egy JVM barat arhitektura kialakitasat, de ezidaig nem jott letre hiaba igergetik evek ota.
IPv6 tamogatas koszoni szepn jol erzi magat most is C-ben. Tipikusan IPv6 egy olyan eset ahol igen fontos szempont a sebbeseg /memoria hasznalat. (Gondolok itt sok giagabit kezelesere)

En pl. minden malloc melle rogton irok egy free-t, meg mielott barmit is irnek a ketto koze (sot van, hogy malloc argumentumanak megadasa elott), ugyan ugy, mint '{','}' nel.

A legtobb driver iro tudomasom szerint C++ kodot is kineveti, nem hogy a javat.
C# "tud" gc-t, es nem interpretalt, de driver ugyileg ebbol sem kerek.

Bar egyes elemzoknek sikerult kihozni (haver meselte), hogy gc biz. esetekben gyorsabb :), csak gratulalni tudok annak aki tul gyakran (re|m)allocozik meg freezik.

Az ipv6-ot csak arra hoztam fel, hogy egyre bonyolultabbak a driverek.

"En pl. minden malloc melle rogton irok egy free-t"
Ha ilyen egyszeru lenne, akkor miert van az a sok memoria kezelesi problema? :) Ez egy bonyolultabb programnal nem ilyen egyszeru.

"A legtobb driver iro tudomasom szerint C++ kodot is kineveti, nem hogy a javat."
En elfogadom, hogy hatekonyabb drivert lehet irni C-ben, de hasonlitsad ossze azokat az erveket, amik a C nyelv es a Java (vagy barmi mas magasabb szintu nyelv) mellett ill. ellen szolnak.

( crown v | 2006. 10. 21., szo – 18:38 )

Kedves gondolat lenne toluk, ha felhasznaloi programokat lehetne ugy futtatni, hogy ne foglaljon le mindegyik sajat, kulon jvm-et, memoriat, hanem valahogy kozoskodjenek, optimalizaljanak. Nekem van memoriam java program futtatasra (pl. eclipse, jalbum...) na de az osszes program java-ban lenne, es ugy inditanam oket, akkor mar lehet beszarna a gepem. Na, ezt kellene megoldaniuk valami frappans huzassal.

Nem jutott eszukbe, hogy ezek a driverek esetleg platform fuggetlenek legyenek? Amugy kiprobalnam szivesen linux alatt, mert itt is van java :) Pl. egy (pentax) kamera driver, pendrive driver lehetne siman java-ban, nem allandoan hasznalom, akkor sem sok idore, akkor meg miert ne legyen java-ban. (vagy perl-ben vagy barmiben, amiben lehet okos drivert irni)

Szepen fejlodnek a VM-ek.
Az 1.5-os JVM-nel mar van lehetoseg arra, hogy tobb JVM kozos memoria teruletet hasznaljon.

Ha odaig "fajul" a dolog, amit bra is irt, akkor meg fogjak oldani. Addig viszont pl. biztonsag szempontjabol nagyon jo igy.

"
Szerzo: bra
A kernelt fogják átírni javába, és csinálnak egy java-processzort, amin natívan fog futni az egész, plusz ha akarod bármilyen OS-en futtathatsz innentől bármennyi Solarist, egymástól teljesen elkülönülve."

Sun 1.5-ös JVM-et fagyasztottam, de egy külső rutingyűjtemény segítségével. Tehát a hiba nem pont a Sun által szállított JVM-ben volt, hanem egy harmadik fél által rosszul megírt .so fájlban. Mondjuk ez nem változtat a tényen, hogy hibás, vagy direkte rosszindulatú .so fájlok megléte esetén elszállásra, majd esetleg kódvégrehajtásra lehet rávenni a JVM-et.

/usr/src/linux/drivers/usb/storage

Keres platform fuggo sorokat, csak linux fugges van, de barmilyen procira jo kod (amin futhat linux is).

Linuxek meg azt sem garantaljak, hogy az api/abi nem valtozik ket verzio kozott. Elsodleges szempont az eroforras hatekonysag.

Eleg furcsa kijelenteni valamirol, hogy platform fuggetlen ami csak egy virtualis gepen fut. (Igaz tobb JVM implementacio is letezik, valamint JVM -et tobb platformra is protoltak)

Es eleg fura lenne tenni egy-egy reteget minden OS -re, hogy u.a. azt a byte kodot, ugyan azzal az API-val megegye.

( znos | 2006. 10. 21., szo – 19:29 )

Van egy ilyen ősi őőőőő... eszkimó! bölcselet, hogy a gepárd gyorsabban fut, mint a csiga, de ha füvet kell enni, akkor a csiga előbb odaér. :D
(Ja, a csiga virtuális gépen fut)
tikk

ejnye, gyerekek... a hír nem erről szólt

( lazyone | 2006. 10. 21., szo – 19:31 )

Nem tudom, van ez a lobby a C-es kernelfejlesztes mellett, hogy ilyen-olyan kernel fejlesztok mellette voksolnak. Szerintem azert mert susuk, arra van limitalva a tudasuk meg esetleg fasza csavoknak erzik magukat tole es meg szado-mazok is raadasul.
A C elavult, a C++ meg kurva bonyolult (es elavult), mindket nyelvben lehet _kurva konnyen_, hatalmas, nehezen debug-olhato ordas bug-okat osszehozni.
Azert en ha beleolvasgatok pl. a linux kernelbe, nincs az az erzesem, hogy jol lenne megszervezve es lekodolva, ir abba mindenki, bolgog-boldogtalan, az a csoda, hogy ugyahogy mukodik.
Teljesitmeny meg eleg LOL. Egy Java program warmup utan ugyanakkora sebesseggel fut mint egy C++-os progi. Java-t is lehet native kodra forditani, nem kotelezo hozza a JVM. Van csomo elonye, reflektiv, runtime tipusinformaciok, stb.
A C/C++-al az is a baj szerintem, hogy bonyolult a nyelvtanja, nehezen ertelmezheto. Ott vannak a makrok, templetek, olyan kod analizatorok kellenek hozzajuk, amik bonyolultak de legalabb lassuak.
Sajnos arra a Java-nal oda kell figyelni, hogy nem a memoria az egyetlen eroforras amit managelni kell. Sajnos ezt sok Java programozo nem tudja, meg a Sun-nal sem. (volt 1x, hogy vmi BufferedFileWriter-nek vagy vmi hasonlonak nem volt meghivva a flush() fuggvenye a destruktorbol (finalize))
Vhogy egy ilyen kernel szintu Java implementacional tobb lehetoseget kellene addni a programozo kezebe a garbage kollektor felett. Pl. az olyan objektumokat amik referencia szamlalo alapjan kimennek a scope-bol, azonnal torolni kellene.
Mind1, hiszek abban, hogy egy Java szeru nyelvvel olyan kerneleket/OS-eket lehet fejleszteni, amik magasan uberelik a C alapu kerneleket es OS-eket, de szerintem nem kellene erosen ragaszkodni a Unix szeruseghez, nagyon sok oskori szar maradt mar benne azokban. (kedvencem a nagy hagyomanyokkal rendelkezo shell-script-eles, ahhol meg az if-nek a '[' zarojelei is kulso programok :) es meg ha memoriaban is vannak mar, akkor is fork()-olni meg minden kernelszintu istenfaszat kell csinalni hozza (a nagy semmiert)... nagyon jo egy ez a shell-script-eles ha Jozsika maganak akar automatizalni egy-ket shell parancsot, de konyorgom, boot-nal ne ilyenek fussanak mar.... Sokkal jobb arra a perl pl.)

C miert lenne elavult ?
Akkor biztos asm is, dobom is ki procimat, mert nem C# ot eszik.

En mar imperativ nyelvtol nem varok csodat, funkcionalis (vagy egeszen mas tipusu) nyelvek kozott fogok keresgelni, hatha talalok valami szepet es jot. Termeszetesen elsosorban nem interpretalt megoldasokkal foglalkozok.

C++ kod tenyleg lassan elemzodik/fordul :(

Shell scripteken tenyleg bukunk sok idot meg memoriat, de szerintem csak tized masodpercet javitana a booton egy atlag gepen, ha asmbliben irtak volna ver profik az init scriptes reszt.
http://ccache.samba.org/
Hasonlisd osze pl: ccache (C), compilercache (Bash) sebesseget. Nem mindig a script/interpreter a legszukebb keresztmetszet.

Nem láttam még Java procit, de gondolom hogy nem közvetlenül Java utasítások kerülnek benne végrehajtásra. Én úgy képzelem el, hogy a JVM a mikrokód egy ilyen prociban és "mögötte" meg valamiféle RISC végrehajtó egység figyel. Úgy mint a mai x86 procik CISC -> RISC megoldásai.

De javíts ki ha tévedek.

A jelenlegi (x86) prociknál úgy működik, hogy:

Java program -> Java bytekód -> JVM program -> CISC ("gépi")kód -> CPU mikrokód (CISC->RISC) -> RISC kód -> utasítás végrehajtás

Egy Java procinál meg működhetne úgy, hogy:

Java program -> Java bytekód -> CPU (JVM) mikrokód (Java->RISC) -> RISC kód -> utasítás végrehajtás

A legfőbb különbség, hogy hagyományos esetben a JVM a központi memóriában fut és történik még egy transzláció a kóddal, Java procinál meg a JVM a CPU memóriájában fut és egyből RISC kódot generál.

Talán ezt akarták szemléltetni ezen az ábrán, csak szerintem nem túl jól.

Egyébként én se értek hozzá, de ahoz képest elég jól eldiskurálunk róla, hogy hogyan lehet... ;))

( ha1dfo | 2006. 10. 22., v – 23:34 )

Emberek!

Azok után, hogy hangszerboltban USB-s gitárt látni, én már nem lepődök meg semmin...

(az 'ember' bedugja az USB-t a gépbe, a ringyóz meg felismeri, hogy plug and play hangeszköz. Nade ha nincs hangkartya, mire megy vele? ha meg van, miért nem tudja oda dugni?)

"A herceg én vagyok."