Ne haragudj, de a szakmai vita érveket szokott jelenteni, nem üres kijelentéseket!
"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.
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!
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?
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:
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.
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.
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.
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.
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 :)
tehát ha ledõl az egyik jvm, akkor most már magával rántja a másikat??? Ugyanmár. Remélem csak a classloaderek egy részét share-elik meg.
FTeR: használd már a google-t. Van már jópár DOOM port (cdoom, edoom)...
Essenmáhó: ja, így van. A Sun nem fogja elkérni a telódat, hogy újraégesse benne a romot :)
BlackRose: neked meg egy közmondást: Disznók elõ veti a gyöngyöt :))) Bár az is igaz, hogy mindíg jó, ha a napfény besüt a barlangba :) A #20-ra meg annyit, hogy jól mondod, csak ne feledjük el, hogy 200 gépes clusteren már annyira nem optimális a windows, hogy nem sokat számít az, hogy az egyes gépeken az MSSQL szerver lenyomja a DB2-t és az Oracle-t (tekintve, hogy a DB2 eleve VMS környezetbe készült, és senki nem veszi komolyan a windows-os változatát...)
Dez: szerintem nézz utána a HotSpot fogalmának. És a ECMA scriptnek. (ECMA? lehet, hogy más sorrendben vannak a betûk )
Az APPLET tag meg megszûnt HTML-ben, szóval inkább ne hívjuk appletnek (uram bocsá programocskának) és pláne ne keverjétek össze a script blokkokat a külsõ objektumokkal (akár applet, akár más) mert még szabvány sértés szerint is máshol kell keresni õket. És mielõtt meg valaki belelovalná magát abba, hogy OS-t nem lehet írni .NET nyelveken (most nem managed kódról beszélek!!!!) annak ajánlom, hogy tegye fel a kérdést magának:
Lehet-e java-ban oprendszert írni??? ;)
googleni mindenki tud.
Természetesen léteznek olyan elemk, amiket c-ben nem tudsz elérni pl virtuális függvények, de ha debuggoltatok már utánna, vagy úgy általában utánna gondoltatok, nem igazán létezek az adott problémára gyorsabb megoldás. Ha ezt c-ben próbálnád emulálni, akkor ugyanarra a megoldásra jutnál, vagy roszabbra... Kiváncsian várom az ellenvéleményeket minden flame nélkül.
ofcoz.
Az igaz, de az is igaz, hogy egy VM méginkább lassít.
te tevedsz, az objektum orientalt elvekhez kapcsolodo absztrakt nyelvi elemek valoban extra overheaddel jarnak.
Az ilyen téves közhiedelemmel próbálnék szembe szállni. Az objektum orientáltság alapvetõen csak egy gondolkodás beli különbség, erõs tulzással csak egy szintaktikai fogalom... A c#, java... természetesen lassú, de még véletlenül sem azért, mert a objektum orientáltak, hanem elsõsorban mert egy vm futtatja a code-odat. Örvendetes módon a JIT cuccokkal már sokat fejlõdtek sebesség terén, de még távol vannak a natív gépikódot eredményezõ nyelvek mögött, persze másra is vannak kitalálva. Erre akartam rávilágítani, a c++ és a .net egy kategóriába sorolásakor, csak lehet, hogy nem voltam egyértelmû... A c++ egyébként is egy speciális nyelv, mivel az egyben magába foglalja a c-t is, ugye visszafelé kompatibilitás miatt így alakult... A c++ nyelvi elemei között nem igazán tudok, talán az exception-öket kivéve aminek gyakori használata érdemben befolyásolhatná a sebességet. Az esetleges sebesség különbségek abból adódhatnak, hogy a fordítók sajnos még mindig nem optimalizálnak elég jól bizonyos dolgokat, pl. általános a visszatérési paraméterek buta használata, vagy pl a visual studio-nál az inlineolás esetlegessége... Mindkét elem c-ben pont ugyanúgy jelentkezik - hisz ugyanazon fordítókat használják az emberek c ill c++ -ra fordításhoz - maximum kisebb ezek száma egy c programban, és így kevésbé esnek kétségbe a fordítók. Sõt okos template metaprograminggal néha még tudsz is gyorsítani c++ -ban dolgokon, és ugye mivel minden c++ fordító egyben c fordító is, te döntheted el, hogy hol milyen elemeket használsz, valóban odafigyelést igényel, de még így is sokkal kényelmesebb az életed, mint c esetén... A Linus féle jobb a kernel c-ben kijelentést nem ismerem, de szerintem nagyobb haszna van olyan szempontból, hogy c-ben írt cuccokat szinte mindenre le tudsz fordítani, c++ -ban - mivel egy nagyságrenddel összetetteb nyelv - akadhatnak problémák, pl a BOOST (http://www.boost.org) is csomó fordító specifikus patch-elést tartalmaz, hogy minél többminden megegye...
A c egyszerûen gyorsabb, mert az Objetum orientáltságnak árai vannak, mégpedig sebesség beli árai. Ha .NET ben akarnánk ilyet irni az gázos lenne , ennyi erõvel JAVA -ban is irhatnánk
"hogy miért ne írnák .NET kóddal az OS-t is, azért mert baromság lenne. Miért van C-ben a Linux Kernel, és nem pedig pl. C++ ban, hát azért mert C-ben gyorsabb kódot lehet írni, optimizáltabbat és stb" C-ben sokkal optimalizáltabb codeot lehet írni? Itt mire gondolsz? Különösen a .NET párhuzam tûnik erõsnek...
1. valamelyik blog fórumában tedd fel a kérdést 2. azért nem a 25 fõ a jellemzõ, és akkor sem azt mondtam, hogy már csak 100 fõs csapatok vannak, hanem hogy nem ritka a 100 fõs se...
Hát... Inkább az AmigaAnywhere-t kellene használniuk... Az pont erre való, csak okosabban (a nevével ellentétben technikailag nincs sok köze a régi AmigaOS-hez, és a Java-hoz sem). A magját (asm-szerû, de cpu-független kód, szuper-optimális fordítással) az a Carl Sassenrath írta, aki annak idején az AmigaOS egyes fõbb komponenseit, késõbb meg a Rebol-t.
Tényleg, kíváncsi lennék errõl Carmack véleményére. Nem tudsz valami elérhetõséget? (El tudom képzelni, hogy esetleg még nem is hallott róla.)
Btw, ahogy kerestem valami címet az Id honlapján, azt találtam, hogy a teljes team (az "utólsó" animátort is belevéve) 25 emberbõl áll, összesen 4 programozóval (Carmack-al együtt), stb. És ez már egy nagyobb csapat. Hol van a többszáz ember, több tucat programozó? :) (Ha emlékszel a korábbi vitánkra. Mindegy, hagyjuk.)
"Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four platforms right now, and not a single pair has the exact same quirks. All the commercial games are tweaked and compiled individually for each (often 100+) platform. Portability is not a justification for the awful performance."
Carmack elkezdte mobilra portolni a Dúmot :D itt a blogja
Végig a javaról ír. Kiemelnék 1 részletet:
"The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything."
Igen, régebben én is csak Javás appletekrõl hallottam, de úgy tûnik, mostanában a JavaScript-es betéteket is appletnek hívják, talán az egyszerûség kedvéért.
Na igen, ez világos. Azt viszont nem értem, hogy sikerült alább a "JavaScript"-et "JavaApplet"-nek [így egyben!] írnom. :) Mindenesetre arra gondoltam, hogy az az SMS-es dolog esetleg egy JavaScript applet, és akkor tényleg nem sok köze lett volna a Java-hoz. (Ha meg Java applet, akkor meg a vonatkozó korlátozások miatt lassabb, nehézkesebb, mint egy normál Java program.)
Igen ez igy van, ha az "applet"-rõl beszélünk, de én azt hiszem, hogy itt kimondottan a "Java Applet"-rõl van szó annak definiciója pedig egyértelmû. Persze nem zárom ki, hogy van JavaScript applet is, de az nem egyenlõ a Java Applet-tel.
A Java applet egy olyan Java nyelven írt program, amit egy sima Java progihoz képest jelentõsen lekorlátoznak, pl. nem írhat a helyi lemezekre, cserébe elfut a böngészõben. Mi legalábbis ezt tanultuk az egyetemen... :)
Amit beidéztél, az még nem zárja ki teljesen, hogy csak és kizárólag Java-ban lehet egy applet. Ki találta ki egyátalán az "applet" kifejezést? A Sun, vagy web megalkotói? Van köze a Sun-nak a JavaScript-hez (úgy tudom, nincs)?
Ha viszont biztos vagy benne, hogy az applet szót csakis a Sun használhatja a Javás appletjeihez, akkor errõl informáljátok azon site-ok üzemeltetõit, mint amit pl. belinkeltem. Tehát gugliba "applet javascript", aztán mehetnek az emailek. :)
Még komolyabb helyeken is olvashatók ilyenek: "Optional: Produce an applet that communicates with the Web page in which it is located, or two or more applets that communicate with each other, using JavaScript."
"An applet is a program written in the JavaTM programming language that can be included in an HTML page, much in the same way an image is included. When you use a Java technology-enabled browser to view a page that contains an applet, the applet's code is transferred to your system and executed by the browser's Java Virtual Machine (JVM). "
az applet egy önálló java programocskát jelöl , ami többnyire böngészõben fut, úgy tudom a lényegi különbség egy java APPLET és egy java PROGRAM között, hogy az applet egy "kis" méretû program interneten könnyen letölthetõ, így kiaknázza a java nyelv elõnyeit, tehát nem kell direkt "belefordítani" a programba minden féle függõ "könyvtárat" /mint a DLL-ek/ , mert elég csak hivatkozni rá és lekapja netrõl a JavaVirtualMachine.. a program viszont tartalmazza a "függõségeket".. de hozzáteszem , hogy SZERINTEM, mert Java nyelvben nem vagyon otthon.
Tudtommal az "applet" kifejezés önmagában annyit tesz: weblapba ágyazott programkód. Vagy ezt is rossz helyrõl néztem? (De akkor a fél web rosszul tudja.)
Igen igazad van, a Sun is éppen akkor követ el baromságokat mint mindenki más is (pl. Microsoft) amikor a ONE SIZE FIT ALL politikát kezdi nyomni és mindenáron semmi racionális alapok nélkül alkalmazni akar valamit ott ahová az alapból nem való. Idõvel persze az ilyen dolgok elkopnak, de mégis sokszor kijavíthatatlan károkat okoznak, a Java is ezt nyögi, nem azért mert lassu, mert nem lassu, csak normális, hogy nem olyan gyors mint a C vagy az assembler... hanem azért mert ott is alkalmazzák ahová nem való és akkor lassunak látszik, ez kb. olyan mintha Dodge Viperrel az F1 versenyre mennél, lassu? NEM, de a Hungaroringen, nevetséges lenne az F1 gépek mezõnyében, hát még akkor képzeljük el Monzában...
"a baj ott kezdõdik amikor valakinek eszébe jut, hogy mindenhová nyomja a Javat, de ez nem csak a Javara vonatkozik, nem való mindenhová és kász, ott ahol lassú oda nem kell használni és kész a megoldás egyszerû. Ez szintén vonatkozik a .NET-re is, valakinek eszébe jutott, hogy miért ne írnák .NET kóddal az OS-t is, azért mert baromság lenne. "
Javíts ki ha tévedek, de a SUN-nál a jávázás a NC-vel (network computer) kezdõdött, ami talán csak JAVA-t tudott volna futtatni, egy natív JAVA processzoron.
Szerintem azon megfelelõ gyors lehetett volna akár OS formájában is, de a JAVA eddig télleg nem volt erre felkészítve. Szal szerintem ezt az OS-ezést nem hülyegyerekek találják ki, hanem a SUN-tól ered. Csak éppen jól elbaromkodták az egészet már az elejétõl.
akkor nézzél utána megint mert ez elég vicces kijelentés :)
Természetesen általánosságban nem gyorsabb a százéves microsoft java futtató mint a sun (windowson sem), viszont lehet egy pár dolog - egyet konkrétan tudok, nevezetesen a tömbökön történõ végiglépdelést - amiben tényleg gyorsabb. Saját szerveralkalmazásra mértem pár éve: a Sun 1.3 java futtatója - pedig már az is nagyon régi - háromszor(!) olyan gyors volt már akkor is mint a microsofté, ami brutális különbség.
Ja, és közben még a procit sem terheli túlzottan. Egyébként asszem nem is az Azureusnak kell a 80 mega, annak a nagy részét a Java környezet egymagában is lefoglalja (pl. mint saját memóriaterület, amibõl utána a futtatott Java programok foglalhatnak). Meg ne felejtsük el, hogy itt run-time fordítás is van (legalábbis korábban még volt, nem tudom, most mi a helyzet, de gondolom, ez nem változott), ahhoz is kell a mem.
Egyszerû, az MS csak Windowsra optimizált, míg a Sun multiplatform, egy kód (nagyjából) minden platformra stb. Ezenkívûl az MS valószinüleg jobban ismeri magát a Windows-ot és ezért képes optimizáltabb kódot írni, ez nem csak a Java VM-nél érezhetõ, hanem pl. az Office-nál is és még egynéhány programnál amelynek van konkurenciája de teljesítményben alulmarad, pl. SQL Server is gyorsabb Windowson mint az Oracle vagy az IBM DB2, stb.
Az hogy lehet, hogy az "eredeti" microsoftos jvm az joval gyorsabb mint a sun-os ?
"A Multi-Tasking Virtual Machine (MVM) prototípusát a Sun barcelonai laboratóriumában fejlesztik"
A Sun-nak nincs barcelonai laboratóriuma, a project neve BARCELONA PROJECT, a fejlesztések pedig a Sun Kaliforniai (Menlo Park) Laboratóriumában folynak... azért ne kövessük már az index.hu-t a téves írásokban.
Ami pedig a Javát illeti, a Javának nagyon is megvan a helye az IT-ben és ott ahol az alkalmazása természetes (tudom, hogy ez hülyéül hangzik, de hirtelen nem tudok jobb kifejezást találni) ott egésszen OK müködik (persze miért ne lehetne még optimizálni), a baj ott kezdõdik amikor valakinek eszébe jut, hogy mindenhová nyomja a Javat, de ez nem csak a Javara vonatkozik, nem való mindenhová és kász, ott ahol lassú oda nem kell használni és kész a megoldás egyszerû. Ez szintén vonatkozik a .NET-re is, valakinek eszébe jutott, hogy miért ne írnák .NET kóddal az OS-t is, azért mert baromság lenne. Miért van C-ben a Linux Kernel, és nem pedig pl. C++ ban, hát azért mert C-ben gyorsabb kódot lehet írni, optimizáltabbat és stb és semmi szükség sincs, hogy C++ ban legyen a Kernel, ezt még maga Linus Torvalds is elutasította, mert akadt egynéhány szuper agy aki ezt ajánlotta. A Java pedig nem lassu, csak nem való mindenhová, a Barcelona Project meg nem kimondottan a Java gyorsaságáról szól "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", vagyis itt inkább a multithread (a multicore CPU-k megjelenése) az ami igazán fontos, a Sun gõzerõvel dolgozik azon, hogy a Java kód minnél hatékonyabb legyen a jõvõ gépein. Ezt maga a Sun Network is a Computer dumája és nem utolsó sorban a Sun Grid Computing fellépése is fókuszpontba hozta.
Aki ketkedik abban, hogy javaban is irhato villamgyors progi, az nezze meg pl az xpand rallyt. Egyik legszebb rally, nagyon gyors engine-el.
attól függ ki méri... Mindenesetre java-t sokkal gyakrabban használnak szerveroldalon mint kliensen.
az egy szar java applet volt .. pl Azureus is java program és ahhoz képest elég gyors, igaz 80 mega memóriát zabál , de közbe 300 tcp/ip és udp kapcsolatot kezel és gigákat tölt le/fel ..
bármiben lehet lassú programot írni. Az igaz, hogy hogy java-ban különösen könnyû lassú vagy legalábbis lassúnak látszó grafikus felületet csinálni. De nem muszáj. Pl. text editornak egy java programot, a jedit-et használom minden nap...
Vajon a C#-nál mennyivel jobb a helyzet sebesség területén? Az is ilyen java konkurrencia.
Én tanultam java-t, és iszonyat lassú tud lenni egy java program GUI-je. Jó példa erre a sajnos megszûnt 777sms.hu, ami java-ban futott, és iszonyatosan lassan frissített képet, miközben az ember pl scroll-ozott az oldalon. (A 777sms.hu-ról jut eszembe: A java-nak megvan az a rossz szokása, hogy az klikkelés eseménykezelõ csak azt veszi klikknek, amikor az egér gombjának lenyomásakor és felengedésekor a kurzor ugyanazon a pixelen van (nem területre hat, mint ahogyan egy gombnál szükséges lenne), így magasabb felbontáson ha nem az egér gomb felengedését kezeljük, akkor sokszor semmi sem fog történni, mint ahogyan én is sokszor csak szenvedtem, hogy végre lenyomjam az elküld gombot. )
sajnos ez a platformfüggetlenség egyik mellékhatása , de legalább próbálnak ezen csökkenteni, ami egy jó pont nekik..
A java futtatók általánosságban nagyon gyorsak, ennek ellenére azt is fejlesztik folyamatosan, ráadásul versengenek egymással is a gyártók. (Ez nem jelenti azt hogy egy java szoftver ettõl még nem lehet lassú, sõt a beépített kódkönyvtár is ineffektív helyenként. Az is igaz, hogy egy nagyobb java alkalmazás zabálja a memóriát) A cikk arról szól, hogy egy bizonyos problémát akarnak kezelni, nevezetesen azt amikor több nagyobb program fut egy gépen. Nem több szál, az eddig is prímán ment, hanem több független program! Ez pl. a mobiltelefonokat aligha érinti... Ez elsõsorban szerveren érdekes, ahol ilyen vagy olyan okból több szerveralkalmazást akarnak futtatni, azért egyetlen szerver alkalmazást akármilyen kis memóriájú gép lazán elvisz...
Csatlakozom.
Rengeteg memóriát zabál. Linuxon meg még többet ahogy megfigyeltem.
Bár látom már írták sokan, de azért én is hozzáteszem, hogy nem árt..
csak az eddig meglévõ telefonokon lévõ futtató környezetet már biztos nem updatelik :(
Hát ideje volt , fõleg hogy jönnek a többmagos procik , amik ténylegesen több szálat tudnak egyidejûleg kezelni ...
igen, már ideje volt (ezzel kellett volna kezdeni...)
idõszerû volt, kissé
Ez szerintem egy nagyon jó dolog. Elvégre (szerintem) a java alkalmazások nem a leggyorsabbak. Van mit fejleszteni rajtuk.
Informatika és tudomány
)
) és pláne ne keverjétek össze a script blokkokat a külsõ objektumokkal (akár applet, akár más) mert még szabvány sértés szerint is máshol kell keresni õket.
De az appletek nem JavaScript-ben vannak?
777sms.hu, ami java-ban futott, és iszonyatosan lassan frissített képet, miközben az ember pl scroll-ozott az oldalon. 
)