67
-
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? -
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 :) -
irkab1rka #57 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. -
alt3r3g0 #56 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. -
Hierogli #55 ofcoz. -
dez #54 Az igaz, de az is igaz, hogy egy VM méginkább lassít. -
Hierogli #53 te tevedsz, az objektum orientalt elvekhez kapcsolodo absztrakt nyelvi elemek valoban extra overheaddel jarnak. -
alt3r3g0 #52 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... -
Benoke #51 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 
-
alt3r3g0 #50 "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... -
FTeR #49 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... -
dez #48 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.) -
FTeR #47 "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." -
FTeR #46 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." -
dez #45 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. -
dez #44 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.) -
BlackRose #43 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. -
#42
Attol fugg ki mit ert applet alatt... a szo altalanos es elfogadott ertelmeben a BlackRose altal leirtakat. -
dez #41 Igen, ez így van, egy Java applet esetén. De ezt eddig is tudtuk (mármint hogy korlátozva van, már csak biztonsági okokból is). -
Kefete #40 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... :) -
dez #39 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." -
BlackRose #38 "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). "
http://java.sun.com/applets/
nem akartam eddig beleavatkozni, de a Java Applet még veletlenül sem JavaScript.
nem ártana még megnézni a következőket sem...
http://www.infoanarchy.org/wiki/index.php/Java_Applet
http://en.wikipedia.org/wiki/Java_applet
na jó szórakozást...
-
![[HUN]PAStheLoD](https://media.sg.hu/forum/avatars/10334754621140968716.jpg "[HUN]PAStheLoD")
#37
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. -
dez #36 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.) -
dez #35 +#31
Elég beírni a gugliba, hogy "applet javascript", és ilyen, és hasonló oldalak tömkelege jön elő:
http://www.popularshareware.com/FolderTree-treeview-JavaScript-Applet-download-458.html -
BlackRose #34 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... -
Hierogli #33 Gyorsabb vagy nem, teny, hogy kliens oldalon a Javat szinte mindenki ruhelli. -
#32
Amen..... 
-
#31
Valamit felreolvashattal szerintem.
De, eleg a kodositesbol. A java applet a java nyelv resze... -
#30
"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. -
dshk #29 akkor nézzél utána megint mert ez elég vicces kijelentés :) -
dez #28 Kicsit utánanéztem (nem foglalkoztam webprogramozással): egy applet lehet Javában és JavaScriptben is. 1:1 :)