[Haderach]

akkor ne offoljuk szet az ezt csinaltam, ... topicot, ezert inkabb folytassuk itt, szoval a tema epp a c++ vs java flame

Idézet

Igazából az 1.5-ös nem nagyon csinál más, mintha egy preprocesszor lenne az 1.4-hez, gyakorlatban a futtató teszi hozzá a typecastokat futásidõben. További info itt: http://www.artima.co.../generics2.html  Igazából az 1.5 majdnem összes új tulajdonsága ilyen varázslatokat használ, talán az annotation-ok nem, bár szerintem ott is valami ilyesmi húzódik meg a háttérben. Egyébként érdekes téma, indíthatnánk neki új topicot.

igen, ezt rebesgettek mar nekem, csak eddig senki olyan nem mondta aki utananezett volna, nekik is csak mondtak, es biztam benne, hogy csak valami c++fan terjeszti

felfoldi kollegatol tovabbra is varom, hogy miert tartja zsakutcanak a c++t

[marczi]

Idézet: Haderach - Dátum: 2005. aug. 3., szerda - 19:15

akkor ne offoljuk szet az ezt csinaltam, ... topicot, ezert inkabb folytassuk itt, szoval a tema epp a c++ vs java flame



igen, ezt rebesgettek mar nekem, csak eddig senki olyan nem mondta aki utananezett volna, nekik is csak mondtak, es biztam benne, hogy csak valami c++fan terjeszti

felfoldi kollegatol tovabbra is varom, hogy miert tartja zsakutcanak a c++t

Nem sajna, én kipróbáltam disassemblerrel, illetve ez úgy ahogy van, kimaradt a Reflection API-ból, ami szintén már eleve erre utalt. Egyébként ez nem jelenti, hogy a Sun egyszer csak nem cseréli ki a JVM-ben ezt valami hatékonyabb kódra. A C++ engem is érdekel!

Szerkesztette: marczi 2005. 08. 03. 20:09 -kor

[Haderach]

Idézet: marczi - Dátum: 2005. aug. 3., szerda - 21:05

Nem sajna, én kipróbáltam disassemblerrel, illetve ez úgy ahogy van, kimaradt a Reflection API-ból, ami szintén már eleve erre utalt. Egyébként ez nem jelenti, hogy a Sun egyszer csak nem cseréli ki a JVM-ben ezt valami hatékonyabb kódra. A C++ engem is érdekel!

hat a JIT nyilvan sokmindent ki tud optimalizalni, es mivel nagyon sok a castolas arra nyilvan kulonosen figyelnek, de a din.tipusellenorzes miatt az meg gepi koddal sem gyors :-/
c++ban viszont elegge otthon vagyok, kerdezz batran

[cx.core]

OFF: Találtam egy ilyet, nem tudom, ismeritek-e.

[Haderach]

Idézet: cx.core - Dátum: 2005. aug. 3., szerda - 22:17

OFF: Találtam egy ilyet, nem tudom, ismeritek-e.

sasolj az alairasomban levo 3 linkre 

[j.cs.]

Idézet

Én azért, mert interpretált, tehát viszonylag lassú. Már a "write once, compile everywhere" gondolkodásmód sem tetszik, nemhogy ez. d3.gif

Ezt írta valaki a másik fórumba... és hát ilyenkor teljesen el tudok képedni, hogy bizonyos dolgokat mennyire nehéz kiölni a köztudatból. Ha a kedves fórumtag ezt 1995-96-ban mondja, akkor minden rendben lenne. De azóta eltelt 10 év.

A helyzet az, hogy ha valaki Java-ban is C-ben programozik (vagyis int, char és társain keresztül implementál algoritmusokat), akkor minimálisan lesz lassabb az adott program annál, mint amit C-ben ír. Sõt, ha mondjuk olyan C fordítója van, ami nem optimalizál a legújabb CPU-kra (vagy esetleg 5 éve fordította le a kódját) a Java környezete meg a legfrissebb, akkor elõfordulhat, hogy a Java kód gyorsabban fut le (mert pl SSE utasításokat is használ a JIT, esetleg inline-ba fordít rövid metódushívásokat, vagy ciklusokat göngyöl ki a HotSpot).

Lehetne errõl a témáról órákat beszélni, de talán nem itt lenne érdemes. Azért pár link:

http://www.idiom.com...Cbenchmark.html

[cx.core]

Idézet: Haderach - Dátum: 2005. aug. 3., szerda - 22:25

sasolj az alairasomban levo 3 linkre 

Úgy láttam, hogy az aláírásodban lévõ FORTRAN-nal kezdõdik, ez meg régebbre nyúlik vissza. Sasolj a kép aljára!

[cx.core]

Idézet: j.cs. - Dátum: 2005. aug. 3., szerda - 22:57

Ezt írta valaki a másik fórumba... és hát ilyenkor teljesen el tudok képedni, hogy bizonyos dolgokat mennyire nehéz kiölni a köztudatból.

Én voltam az a valaki. Azt tudom neked tanácsolni, hogy ne próbálj megítélni, mert nem ismersz.
Viszont értékelem, hogy nem próbálod meg elmagyarázni, hogy a Java nem interpretált.

Szerkesztette: cx.core 2005. 08. 03. 22:23 -kor

[marczi]

Idézet: cx.core - Dátum: 2005. aug. 3., szerda - 22:02

Én voltam az a valaki. Azt tudom neked tanácsolni, hogy ne próbálj megítélni, mert nem ismersz.
Viszont értékelem, hogy nem próbálod meg elmagyarázni, hogy a Java nem interpretált.

Én azért megpróbálom 1.3-tól fölfelé az interpreteren kívül a JIT a másik végrehajtó modulja a JVM-nek. A JIT viszont compiler, legalábbis nehéz ráfogni, hogy interpreter. Jó ideig ha JIT módban futtattál Java programot, akkor nem is lehetett debuggolni kívülrõl, ezt csak az 1.4 szüntette meg.

Szerkesztette: marczi 2005. 08. 03. 23:27 -kor

[Haderach]

Idézet: cx.core - Dátum: 2005. aug. 3., szerda - 23:02

Én voltam az a valaki. Azt tudom neked tanácsolni, hogy ne próbálj megítélni, mert nem ismersz.
Viszont értékelem, hogy nem próbálod meg elmagyarázni, hogy a Java nem interpretált.

neztem 

[Haderach]

Idézet: j.cs. - Dátum: 2005. aug. 3., szerda - 22:57

http://www.idiom.com...Cbenchmark.html

ezzel a teszttel csak az a baj, amit mar az elozo linkelt cikkben is kiveseztek: a szintetikus tesztek itt semennyire sem mervadok. numerikus problemak nem relevansak. egy JITet siman meg lehet tanitani, hogy optimalizaljon nagy tombokben osztasra, szorzasra, stb... mint az allat, ezzel nyilvan nincs semmilyen problema, am a valos eletben az alkalmazasok nagy resza a futasi idejenek dominans reszet csunya elagazasok toltik ki, illetve millio castolas. ezekkel pedig a JIT nem tud mit csinalni, illetve a castolassal tud, de az mindenkepp sok, akar lassu, akar gyors. szinten nem nagyon tud sokat optimalizalni a fuggvenyhivasokon, ellenben a C/C++ programokkal. szoval lehet, hogy numerikus tesztekben megkozeliti, akar el is hagyja oket, de konzervativ kod futtatasa eseten nem lesznek meg jo ideig versenytarsak.
(ennek ellenere a java nagyon jol hasznalhato nyelv szvsz, de nem azert mert gyors )

[marczi]

Idézet: Haderach - Dátum: 2005. aug. 4., csütörtök - 9:51

ezzel a teszttel csak az a baj, amit mar az elozo linkelt cikkben is kiveseztek: a szintetikus tesztek itt semennyire sem mervadok. numerikus problemak nem relevansak. egy JITet siman meg lehet tanitani, hogy optimalizaljon nagy tombokben osztasra, szorzasra, stb... mint az allat, ezzel nyilvan nincs semmilyen problema, am a valos eletben az alkalmazasok nagy resza a futasi idejenek dominans reszet csunya elagazasok toltik ki, illetve millio castolas. ezekkel pedig a JIT nem tud mit csinalni, illetve a castolassal tud, de az mindenkepp sok, akar lassu, akar gyors. szinten nem nagyon tud sokat optimalizalni a fuggvenyhivasokon, ellenben a C/C++ programokkal. szoval lehet, hogy numerikus tesztekben megkozeliti, akar el is hagyja oket, de konzervativ kod futtatasa eseten nem lesznek meg jo ideig versenytarsak.
(ennek ellenere a java nagyon jol hasznalhato nyelv szvsz, de nem azert mert gyors )

Meg hát az a lassú, amikor szinkronizált függvények garmadát használják a programozók ott, ahol nem kéne lásd Vector <-> ArrayList. De igazából egy program futási sebességét lényegesen növelik a programozó kvalitásai

[cx.core]

Idézet: marczi - Dátum: 2005. aug. 4., csütörtök - 0:18

Én azért megpróbálom 1.3-tól fölfelé az interpreteren kívül a JIT a másik végrehajtó modulja a JVM-nek. A JIT viszont compiler, legalábbis nehéz ráfogni, hogy interpreter. Jó ideig ha JIT módban futtattál Java programot, akkor nem is lehetett debuggolni kívülrõl, ezt csak az 1.4 szüntette meg.

Most akkor kattints a linkre, amely a(z általad is idézett) hozzászólásomban található! :Ð

Szerkesztette: cx.core 2005. 08. 04. 10:01 -kor

[SFIJ]

Idézet: Haderach - Dátum: 2005. aug. 3., szerda - 19:15

felfoldi kollegatol tovabbra is varom, hogy miert tartja zsakutcanak a c++t

nos en nem vagyok felfoldi, de:

a) a c++ syntactic sugar-ja valami elementaris. gyakorlatilag nincs olyan c++ compiler ami barmilyen, meg legalis c++ kodot le tudna forditani
b) altalaban hosszu ideig tart egy c++ kod forditasa
c) a nyelv definialt, de a runtime model es az abi nem. ez azt jelenti, hogy egyazon platformon kulonbozo forditok altal letrehozott objecteket nem lehet osszelinkelni.
d) a c++ projectek mindig a kerek ujra feltalalasaval kezdodnek. nincs hozza rendes, definilat gui/net/whatever lib, ezeket mindenki kifejlesztgeti a maga szamara, horribilis koltsegekert.
e) a nyelv nehezkes es szoszatyar
f) kozepes tudasu programozok katasztrofalis kodokat hoznak benne letre, aztan nezi a faszikam, hogy mert rossz a kodja es lehet neki fel oraig magyarazni, hogymert baromsag az, amit megirt
g) vanis explicit memoriakezeles meg nem is: divatosak a mindenfele smart pointerek, hogy ne kelljen kezzel kovetni a mem allokalasokatat, ellenben a programozok sok esetben nem ertik az ilyen cuccok elettartamat.
h) a c++ kodot iszonyat nehez optimalni ha sok forrasfile-bol namespace-bol all a project.
i) a c++ kodok memoria igenye hatalmas, az optimalisnak nem ritkan 2x-3x osa.

[h1ghland3r]

Idézet: SFIJ - Dátum: 2005. aug. 4., csütörtök - 9:12

nos en nem vagyok felfoldi, de:

a) a c++ syntactic sugar-ja valami elementaris. gyakorlatilag nincs olyan c++ compiler ami barmilyen, meg legalis c++ kodot le tudna forditani
b) altalaban hosszu ideig tart egy c++ kod forditasa
c) a nyelv definialt, de a runtime model es az abi nem. ez azt jelenti, hogy egyazon platformon kulonbozo forditok altal letrehozott objecteket nem lehet osszelinkelni.
d) a c++ projectek mindig a kerek ujra feltalalasaval kezdodnek. nincs hozza rendes, definilat gui/net/whatever lib, ezeket mindenki kifejlesztgeti a maga szamara, horribilis koltsegekert.
e) a nyelv nehezkes es szoszatyar
f) kozepes tudasu programozok katasztrofalis kodokat hoznak benne letre, aztan nezi a faszikam, hogy mert rossz a kodja es lehet neki fel oraig magyarazni, hogymert baromsag az, amit megirt
g) vanis explicit memoriakezeles meg nem is: divatosak a mindenfele smart pointerek, hogy ne kelljen kezzel kovetni a mem allokalasokatat, ellenben a programozok sok esetben nem ertik az ilyen cuccok elettartamat.
h) a c++ kodot iszonyat nehez optimalni ha sok forrasfile-bol namespace-bol all a project.
i) a c++ kodok memoria igenye hatalmas, az optimalisnak nem ritkan 2x-3x osa.

j) Eleve nem lehetett volna a namespace rendszert valahogy osszegyogyitani valami unit szisztemavall? Helyette van nekunk namespace+preprocesszor C++-ban. Egy bugyuta preprocesszor.... Ellenben ott vannak a sokkal jobban atlathato es ugyanolyan hatekony szisztema (lassan tiz eve) Object Pascal-ban, Javaban, C#-ban. Es halistennek nem kell komplikalt makefile vagy fuggoseg eszleleses make a forditashoz, hanem a forditoprogram kepes megoldani a problemat.

g) Szalkezeles, szinkronizacios primitivek, interprocess kommunikacio, elosztott mukodes meg nyomokban sincs benne a standard konyvtarban. Pedig benne lehetne, sot benne kellene lennie. Az elosztott mukodes problematikaja nagyreszt az ABI es a runtime model sokfelesegenek van kiszolgaltatva. Van ezekre nemi probalkozas a boost-ban, de meg sajat bevallasuk szerint is elegge kezdetlegesek.

h) Amiert viszont abszolut zsakutca, az az, hogy a forditoprogram irok abszolut le vannak maradva a szabvany mogott, ami szabvany teljesen le van maradva onmaga mogott. Es ha (ismetlem HA) egyszer megjelenik az uj, akkor sem fog tudni magan segiteni, mert a forditoprogramok baromi lassan fogjak felvenni a fonalat. Mikor is jelent meg pl. a reszleges template specializacio a szabvanyban? Es mikor jelent meg a gcc-ben? Valamikor a 3.0 kornyeken. Es mikor jelent meg a Microsoft forditoban? Allitolag a 7.0 volt az elso, ami tenyleg tudta.

Ekozben egy C# objektum olyat tud (a nyelv szemantikajaba illeszkedo modon), hogy kozvetlenul hivogatja egy masik gepen elhelyezkedo objektum metodusat. Nem kell hozza CORBA v. DCOM interfeszekkel, stubokkal, marshallinggal meg a tobbi baromsaggal torodni. Sot meg tudom mondani egy objektumnak, hogy vonszolja at a belet a tavoli gepre. Igy elsore ossze birnank hozni kismillio okot, amiert ezt baromi korulmenyes megtenni C++-bol. Es mennyivel tobb problema ez, ha Linux-Windows viszonylatban szeretned ezt megtenni. Es ehhez nem kell virtualis gep, csak szabvanyositani kellene az objektumok felepiteset.

Egy jo pelda ide az objektumorientalt adatbazisok (OODBMS) kerdese. C++-on csomo tokeletlenkedes van vele (perzisztens ososztalybol virtualis leszarmazas, adattipusok platformonkent koszono viszonyban sincsenek, sajat new() operator, pointer membereket Link<> template-ekre kell lecserelni, explicit dirty()-t kell hivni a megvaltozott objektumokra) mire csinalhatsz egy perzisztens objektumot. Csereben egy  C# kodban egy nyamvadek [Persistent] attributumot kell odabiggyeszteni az osztaly definiciojahoz, illetve a letrehozott objektumok kozul a tarolni szuksegeseket be kell regisztralni a session-ben es kesz.....

Fortran, Cobol

Idézet

a a a a a ugy biztosnem, azokat a nyelveket meg viragzasuk alatt SEM szerette senki a c++ ezen pedig azert mar tul van

Ez nem igaz. A Fortran-t viragzasa idejen mindenki szerette, mert nem volt mas es olyan aldas volt  az 50-60-as evek mernoki alkalmazasfejlesztoinek, mint az eldobhato pelenka es az automata mosogep a haziasszonyoknak. Ja es a Fortran forditok legalabb megbizhatoak voltak a szabvanyok tekinteteben.

A Cobol-rol nem nyilatkozok, azt sosem hasznaltam....

Szerkesztette: h1ghland3r 2005. 08. 04. 12:43 -kor

[marczi]

Idézet: cx.core - Dátum: 2005. aug. 4., csütörtök - 10:00

Most akkor kattints a linkre, amely a(z általad is idézett) hozzászólásomban található! :Ð

Olvastam és ismerem a Sun-os linket, de sajna a Sun '95 óta kinn hagy minden szemetet a weboldalán. De hogy szintén a Suntól jöjjön link, itt hasonlítgatják össze a JIT és az interpretált mód sebességét:
http://java.sun.com/developer/onlineTraini.../perf2.html#jit
Illetve az 1.4 óta compilerként hivatkoznak rá: http://java.sun.com/products/hotspot/docs/...4.1_1002_4.html

Ha veszel egy 1.4.2-es Java-t és beírsz egy "java -X"-et, akkor láthatod, hogy van mixed mód, ahol interpretál, majd a hotspot futtatja a már fordított kódot (-Xmixed), van interpreter only mód (-Xint), és van fordított mód, amikor nincs interpreter (-Xcomp)

Sõt, ilyenkor olyanannyira nem interpretált, hogy pl. VM a NullPointerException, ArrayOutOfBoundsException esetén is az oprendszer által generált exceptiont kapja el, nem pedig õ ellenõrzi futás elõtt.

De ha mondjuk IBM JVM-et használsz, akkor a szintén JIT módban futtat:
http://www.trl.ibm.c...jit/index_e.htm
(meg az 1.2.2-es JRE is, ami a Symantec JIT fordítóját használja)

Bár lehet, hogy nem annyira mérvadó, mint a Sun saját oldala, de pl. a wikipedia és a freedictionary is megkülönbözteti a két módot:
http://en.wikipedia.org/wiki/Jvm
http://computing-dictionary.thefreediction...com/Java%20chip

Persze azt mondhatod, hogy a JIT mód is interpretált futtatás, de ugye csak az elsõ futásnál, szóval erre talán erõs azt mondani, hogy a Java interpretálva fut. Azért nem lehet szerintem kijelenti, hogy a Java, mint nyelv interpretált, mert futtathatod Java processzoron (pl. MAJC), fordíthatod natívra (gcj), használhatsz teljes futásidejû elõrefordítást (Excelsior JET, JRockit).

Végül is, az egész csak arról szól, hogy mit nevezel interpreternek, mert végül is manapság az x86 kód is csak egy interpretált nyelv Szerintem egyáltalán nem triviális eldönteni, hogy hol a compiler és az interpreter között a határ. Én ma úgy mondanám, hogy a gyengén típusos nyelvek interpretáltak (Perl, PHP, Python, shell scriptek), az erõsen típusos nyelvek pedig napjainkban jellemzõen vagy a statikusan fordítottak (C, C++), vagy pedig a dinamikus fordítottak (Java, C#)

Peace

[Haderach]

Idézet: h1ghland3r - Dátum: 2005. aug. 4., csütörtök - 13:01

Fortran, Cobol

Ez nem igaz. A Fortran-t viragzasa idejen mindenki szerette, mert nem volt mas es olyan aldas volt  az 50-60-as evek mernoki alkalmazasfejlesztoinek, mint az eldobhato pelenka es az automata mosogep a haziasszonyoknak. Ja es a Fortran forditok legalabb megbizhatoak voltak a szabvanyok tekinteteben.

A Cobol-rol nem nyilatkozok, azt sosem hasznaltam....

oke, en sem hasznaltam meg, de rosszat mar hallottam nagyon boven 

[cx.core]

Idézet: marczi - Dátum: 2005. aug. 4., csütörtök - 13:38

Peace

Idézet: cx.core - Dátum: 2005. márc. 19., szombat - 22:53

Igen, tudom, van lehetõség az egész bytecode egybeni lefordítására futtatás elõtt. (És még így is lassabb lesz, mintha egybõl az adott architektúra natív kódjára fordítottad volna.)

Többek között ez is olvasható ott, ahová az a link mutat. Ha ezt is elolvastad, akkor nem értem, miért magyarázol.

Azért írtam, hogy a Java interpretált, mert ilyennek alkották (tervezték) meg, és véleményem szerint ez a mérvadó, nem az, hogy le lehet-e fordítani (ugyanis nyilvánvalóan minden interpretálható nyelvet le lehet fordítani). Ha már a kezdetektõl kétlépcsõs fordításon alapuló nyelvnek tervezték volna, akkor másmilyen lenne. Nyilvánvalóan más szempontok érvényesülnek egy interpretált és egy nem interpretált nyelv tervezésekor. (Ha hordozható nyelvet fejlesztesz, amely a magasszintû forráskódokat a gazdaságos átvitel érdekében tömöríti, tokenizálja, akkor nyilván nincs szükséged rá, hogy ez az átmeneti kód jól interpretálható legyen.) Azzal is tisztában vagyok, hogy a modern x86 családba tartozó processzorok valójában egy RISC-szerû magból és egy interpreter/decoder rétegbõl állnak - de ettõl még nem lesz interpretált az x86 "nyelv", mivel eredetileg nem annak tervezték.

Amikor fordítást végzel két nyelv között (és ez nem egy az egyhez típusú megfeleltetés, mint pl. az ASM-k esetében), akkor mindig pazarolsz egy kicsit - hogy mennyit, az esetfüggõ. De ha kétszer fordítasz, akkor kétszer pazarolsz, nincs mese.

Mondjuk egy 8086 natív kódot valamilyen RISC architektúra kódjára "lefordító" program létrehozása feltehetõleg nem jár különösebb nehézségekkel (mivel a 8086-on nincs védett mód), de a "lefordított" x86 kód kevésbé lesz hatékony, mintha eredetileg arra a bizonyos RISC-re kódolták volna. A Java filozófia erre még rátesz egy lapáttal: (a fenti példánál maradva) az eredeti x86 kódot sem kézzel (vagy ASM-ben) írták, hanem mondjuk C-ben. Tehát az eredeti algoritmusnak, amit kigondoltak, a C implementáció már csak tökéletlen vetülete, amelynek az x86 szintén, és amelynek az ominózus RISC kód megint csak. És ez szerintem nem vezet semmi jóra.

Az engem hidegen hagy, hogy a Java sebessége (mûanyagszagú tesztekben)  hogyan viszonyul a C vagy a C++ sebességéhez, ugyanis nem vagyok sem C, sem C++ fan. Engem csak az izgat, hogy már C-ben sem érzem azt a fajta kontrollt a HW fölött, amit ASM-ben. (És aki Z80 ASM-ben kezdte, az már gondolom az (instruction $-sel, OoOE-nel meg branch predictorokkal megbolondított) x86 kapcsán is érzi ezt.) De cserébe a C-t a programozói kultúra elég nagy része (UNIX kultúra) "beszéli". A Java számomra csak egy újabb réteget jelent; egy újabb banánhéjat a lábam alá.

Peace

[marczi]

Idézet: cx.core - Dátum: 2005. aug. 4., csütörtök - 13:27

Többek között ez is olvasható ott, ahová az a link mutat. Ha ezt is elolvastad, akkor nem értem, miért magyarázol.

Azért írtam, hogy a Java interpretált, mert ilyennek alkották (tervezték) meg, és véleményem szerint ez a mérvadó, nem az, hogy le lehet-e fordítani (ugyanis nyilvánvalóan minden interpretálható nyelvet le lehet fordítani). Ha már a kezdetektõl kétlépcsõs fordításon alapuló nyelvnek tervezték volna, akkor másmilyen lenne. Nyilvánvalóan más szempontok érvényesülnek egy interpretált és egy nem interpretált nyelv tervezésekor. (Ha hordozható nyelvet fejlesztesz, amely a magasszintû forráskódokat a gazdaságos átvitel érdekében tömöríti, tokenizálja, akkor nyilván nincs szükséged rá, hogy ez az átmeneti kód jól interpretálható legyen.) Azzal is tisztában vagyok, hogy a modern x86 családba tartozó processzorok valójában egy RISC-szerû magból és egy interpreter/decoder rétegbõl állnak - de ettõl még nem lesz interpretált az x86 "nyelv", mivel eredetileg nem annak tervezték.

Amikor fordítást végzel két nyelv között (és ez nem egy az egyhez típusú megfeleltetés, mint pl. az ASM-k esetében), akkor mindig pazarolsz egy kicsit - hogy mennyit, az esetfüggõ. De ha kétszer fordítasz, akkor kétszer pazarolsz, nincs mese.

Mondjuk egy 8086 natív kódot valamilyen RISC architektúra kódjára "lefordító" program létrehozása feltehetõleg nem jár különösebb nehézségekkel (mivel a 8086-on nincs védett mód), de a "lefordított" x86 kód kevésbé lesz hatékony, mintha eredetileg arra a bizonyos RISC-re kódolták volna. A Java filozófia erre még rátesz egy lapáttal: (a fenti példánál maradva) az eredeti x86 kódot sem kézzel (vagy ASM-ben) írták, hanem mondjuk C-ben. Tehát az eredeti algoritmusnak, amit kigondoltak, a C implementáció már csak tökéletlen vetülete, amelynek az x86 szintén, és amelynek az ominózus RISC kód megint csak. És ez szerintem nem vezet semmi jóra.

Az engem hidegen hagy, hogy a Java sebessége (mûanyagszagú tesztekben)  hogyan viszonyul a C vagy a C++ sebességéhez, ugyanis nem vagyok sem C, sem C++ fan. Engem csak az izgat, hogy már C-ben sem érzem azt a fajta kontrollt a HW fölött, amit ASM-ben. (És aki Z80 ASM-ben kezdte, az már gondolom az (instruction $-sel, OoOE-nel meg branch predictorokkal megbolondított) x86 kapcsán is érzi ezt.) De cserébe a C-t a programozói kultúra elég nagy része (UNIX kultúra) "beszéli". A Java számomra csak egy újabb réteget jelent; egy újabb banánhéjat a lábam alá.

Peace

Ej, régi szép idõk, jó kis Z80 a ZX Spectrumban De valóban, az x86 folyamatos mankózása valóban elég zavaró, fõleg, ha mondjuk egy Motorola 6x000 procit nézek, vagy valami jó kis 32 bites Hitachi mikrokontrollert.

Valószínûleg nem is az a cél, hogy a hardver fölött rendelkezz, hanem - ha végletesen akarok fogalmazni - hogy gyorsabban tudd megírni az ügyviteli rendszeredet, esetleg gyorsan tudjál prototípust készíteni. Komplex rendszereket nagyon költséges (idõ/pénz) alacsonyszintû nyelven írni, és szerintem a C# meg a Java nem a végállomás még ebbõl a szempontból. Gyanítom, hogy nincs olyan messze, amikor újabb nyelvi kiegészítések és absztrakciók jönnek be (akár valami Objective C-szerû, akár valami Eiffel szerû), illetve jönnek az újabb rétegek, pl. nálunk egyre több minden készül Pythonban, pl. simán elpofázgat egy RS-232 buszon lévõ hõmérõkkel.

Én nem abban látom a veszélyét ennek, hogy újabb rétegek vannak, amik miatt gyorsabb procik kellenek, meg kevesbé rendelkezel a vas fölött. Nekem inkább az a bajom, (legalábbis amikor tanítok, ezt tapasztalom), hogy mintha az lenne a tendencia, hogy a programozók új generációjának fogalma sincs arról, hogy mi történik, amikor akár egy Java program fut. Vagy hogy egy objektum mondjuk mi is lehet, és hogyan mûködik, hogyan ábrázolják. Ez leginkább egyébként multi-threades problémáknál jön elõ, mert az alacsonyszintû ismeretek nélkül nem csoda, hogy mondjuk egy versenyhelyzetet nem tudsz elmagyarázni. Szerintem ennek ez a legnagyobb veszélye.

[SFIJ]

Idézet: h1ghland3r - Dátum: 2005. aug. 4., csütörtök - 12:01

Sot meg tudom mondani egy objektumnak, hogy vonszolja at a belet a tavoli gepre. Igy elsore ossze birnank hozni kismillio okot, amiert ezt baromi korulmenyes megtenni C++-bol. Es mennyivel tobb problema ez, ha Linux-Windows viszonylatban szeretned ezt megtenni. Es ehhez nem kell virtualis gep, csak szabvanyositani kellene az objektumok felepiteset.

nem eleg. a 'vonszold at a beled' az lenyegeben azonos az objektum szerializalasaval. ezt megtenni alapbol csak interpretalt nyelvvel lehet, c++-szal csak akkor ha azonos a CPU, az OS es a futasi kornyezet.