[Sanyix]

@attila9988: kb semmi elõnye nem lenne. Sem több szál, sem változna a directx 7 szintû render moderebbre.
Ja azért mellesleg nem csak ugyan azt tudja mint az elõdje, kapott egy full dinamikus árnyékolást, jobb fénykezelést, fényévekkel jobb AI-t, és jobb fizikát, és így gyorsabb.

"Mindaddig amíg egy köztes réteg mindenfajta feladatokat lát el a program futása közben, nem lesz soha jobb vagy gyorsabb a java/.net kód."
Kivéve akkor amikor a JIT futás közben optimalizál a körülményektõl függõen, ami natívnál nem történhet meg.

[Sanyix]

@attila9988: nem tudom mi nem volt érthetõ az írásomban. Azonos gépen az új engine-el ugyan az a tartalom, 2-3-4x olyan gyorsan fut mint az eredeti natív, ráadásul jóval stabilabb is.

[attila9988]

@Sanyix: A jit fordító is önámítás. Attól hogy egyes eljárásokat natívra fordít, és azt hivogatja, még ugyanúgy kelleni fog a köztes réteg az olyan feladatok elvégzésére, amiket nem adhatsz meg manuálisan. Pl ugyanúgy kell gc -znie, amit ugyanúgy ellenõrizgetnie kell idõnként, valamint a jit -ezés sincs ingyen, azt is el kell végezni akár menet közben is, ami memória+proci idõ.

Kissé túl van értékelve az egész koncepció, pláne hogy még mindig minimum kétszer lassabb a java mint a c++, és kb négyszer annyi memória is kell neki.

Mindehhez még hozzájön a kódolási stílus is. Pl az ilyen gc -s nyelveken ha kell neked egy "kutyafasza" objektum, akkor példányosítasz egyet, és kész. Ezt teszed mindenütt, és nem tervezel vele, hiszen eldobható szemét lesz minden objektum, és így is alkalmazod õket. Ezzel több munkát adsz a vm -nek, és kevésbé optimális eredményt produkálsz.

Egy szó mint száz, a vm -es nyelvek nem érnek a natív -ak nyomába ha komoly dolgokról van szó. Nem véletlenül jön megint fel a c++....

[attila9988]

@Sanyix: " Azonos gépen az új engine-el ugyan az a tartalom, 2-3-4x olyan gyorsan fut mint az eredeti natív, ráadásul jóval stabilabb is."

Ez azért nem igaz, mert az eredeti játék elmegy egy p1 -esen is, az új meg nem....

[attila9988]

@attila9988: Ja, és egyébként sem fut a játék gyorsabban, hanem egyszerûen csak nagyobb fps értéket produkál, sokkal, azaz SOKKAL több erõforrás árán.

[attila9988]

Nem mellesleg végnyomtam a quake2 java -s változatát, és nem láttam benne semmi eget rengetõ változást, leszámítva a sokkal nagyobb gépigényt.

[attila9988]

Ja és még valami... érdemes megfigyelni, hogy amikor ócsárolják a java vagy .net programokat hogy lassúak, és konkrét megnevezett alkalmazásról van szó, akkor mindig jön valaki megmagyarázni, hogy pl az eclipse nem azért lassú... az ati vezérlõpult sem azért lassú... a minecraft sem azért lassú... Pedig dehogy is nem... A memóriát meg aztán egyértelmûen azért zabálják.

[attila9988]

Hogy még egy kicsit kötekedjek... Ha annyira jók és gyorsak a vm -es nyelvek, akkor hogy lehet hogy az oprendszerek legbelsõbb lelkivilágán nem egy vm fut, amin megvalósítanának minden funkciót? Volt ilyen jellegû kísérleti pfoject -je a microsoft -nak is, aztán a mai windows -ok mégsem ilyenek... Na vajon miért nem?

[hanischz]

@Sanyix: "Kivéve akkor amikor a JIT futás közben optimalizál a körülményektõl függõen, ami natívnál nem történhet meg."

Most mar vegre tenyleg igy van? Mert par evvel ezelott a .NET futtato nem birta kioptimalizalni egy sima ciklusban egy adattag elereset. Ha en csinaltam manualisan a ciklus elott es tettem be egy valtozoba akkor sokkal gyorsabb lett

Szoval ez a marketingesek altal egy evtizede hangoztatott dolog vagy mar vegre tenyleg implementaltak?!

[Sanyix]

@attila9988: persze elmegy p1-en, bár az fps-t csak tört számmal lehetne ábrázolni. De valószínûleg a .net-es is elmegy rajta. De nincs olyan állat aki egy p1-en akarná futtatni, éppen ez volt a lényeg, hogy a modern gépeket ki tudja használni, és kijavítsa az eredeti bosszantó hibáit, és új lehetõségeket implementáljanak benne.

"a, és egyébként sem fut a játék gyorsabban, hanem egyszerûen csak nagyobb fps értéket produkál"

uhhh.... értem szóval nem gyorsabb, de gyorsabb D
A quake2-nek éppen az volt a célja, hogy javaban összerakják ugyan azt és annyi milyen változást vártál még? És ahhoz képest hogy szerinted a natív 2x gyorsabban fut, még is hozza a javas q2 is a natív teljesítmény 90%-át.

Az oprendszerek belsejében talán azért nem vm fut, mert a vm nehezen tud futni a semmin. Tudod a tojás sem csak úgy terem, hanem a tyúkból jön. Nem volt ilyen kísérlete az m$-nek, de ha lett volna sem jelent semmit hogy nekik nem sikerült... nekik más sem sikerül szegényeknek csak a vendor lock-in.

"A memóriát meg aztán egyértelmûen azért zabálják." hú azt aztán tényleg nagyon zabálják, ez a felújított játék .net alapon is megeszik akár 140 mega ramot is (ha nincsenek beleszámolva a ramhasználat túlnyomó részét kitevõ textúrák, modellek és hangok amiket natív nem natív, úgy is be kell tölteni), tényleg egetrengetõ ram használat... lett volna, 13 éve
Az a jópár másodpercenként lefutó GC is akkora gondot jelent hogy észre se venni.

[attila9988]

@Sanyix: "persze elmegy p1-en, bár az fps-t csak tört számmal lehetne ábrázolni."

http://gamesystemrequirements.com/games.php?id=603

Ezen a gépen hogy futna az "új" változat? A recommended ágat nézd ha lehet... azon minden tökéletes.

"uhhh.... értem szóval nem gyorsabb, de gyorsabb D"

Szóval az neked gyorsabb futás, hogy 10x -es hardverigénnyel több fps -t produkál? Mert hogy a régit nem a hardver korlátozta az fps számban egy mai gépen.

"még is hozza a javas q2 is a natív teljesítmény 90%-át."

Úgy hogy szénné terheli a cpu -t és 400+ mb -ot zabál menet közben? Az eredetinek 16 kellett. Alig 25x annyi memória kell neki... ilyen ez a "modern" technika..

"Az oprendszerek belsejében talán azért nem vm fut, mert a vm nehezen tud futni a semmin."

Mert mit is írtam én? Azt hogy:
"oprendszerek legbelsõbb lelkivilágán nem egy vm fut"...

Vagyis amire én gondoltam, hogy a kernel szint felett, technikailag akár futhatna egy vm is, de mégsem így van. A microsoft régen foglalkozott ezzel a dologgal, de nem lett belõle semmi. Mit gondolsz miért?

"Nem volt ilyen kísérlete az m$-nek,"

De volt... több cikk is említést tett róla az utóbbi idõben is.

"Az a jópár másodpercenként lefutó GC is akkora gondot jelent hogy észre se venni."

Az plusz meló nem? De igen... akkor meg?

[attila9988]

Egyébként volt egy ilyen java -s vitám is valakivel, aki meg akarta magyarázni nekem, hogy mivel a vm nem használja a teljes lefoglalt heap területet, ezért az nem foglalt memória.... márpedig dehogy nem, hiszen az operációs rendszer nem használhatja fel másra azt a területet, amit a vm lefoglal magának, ergo kurvára mindegy hogy abban épp hasznos objektumok vannak, vagy épp üres, mert pont végment rajta a gc.

['Geri']

gondolom VÉLETLENÜL sem a directx lehet a mókában a szűk keresztmetszet