[Jakuza]

Idézet: SFIJ - Dátum: 2006. jún. 15., csütörtök - 0:06

nézd jakuza. osztottam, szoroztam, 300 ezret kellett volna gépre költenem ehhez a játékhoz. ehelyett költöttem hw-re 90-ezret, a gáma DVD meg 17 ezer volt. megvagyok harmadáron.

SFIJ itt egy kicsit masrol beszeltem.
Viccnek szantam a mondandomat.
Tudod oblivion = felejtes tehat elfelejteni a boxosokat es nem a konzolra ertettem, ha erted.
Mindent tul komolyan vesztek.
A te dolgod mit csinalsz amugy sajat vagyonkaddal, ha neked az esik jol hogy Xboxozni, PCzni, Retro gepet gyujteni akarsz a te sajat dolgod.
Amugy sincs senkinek abba beleszolasa, hogy te mit tartasz helyesnek, addig a pillanatig ha masranezve nem serto a dolog.

[SFIJ]

Idézet: vers - Dátum: 2006. jún. 14., szerda - 23:08

te félrebeszész
a programok nagysága max  pár mega, a grafikák zabálnak  ablakonként , az meg ugyis a másik memoba megy
130 megás office LOLLLLLLLLLLLLLLLLLLLLLL, nekem elég lesz egy 100kilos szövegszerkesztö is

khmm...

Csatolt fájl:

•  task.jpg (0byte)
  Letöltések:: 0

Szerkesztette: SFIJ 2006. 06. 14. 23:42 -kor

[SFIJ]

Idézet: hvuk - Dátum: 2006. jún. 14., szerda - 23:12

Nem velem nem lehet vitatkozni. Aki "anyám borogass!", meg hasonló kijelentéseket hoz érv helyett, azzal nem lehet mit kezdeni. Mi volt a bajod azzal a hozzászólással?

1. állítok valamit
2. nem hiszed el. nem mondod meg hol hibás, csak ex catedra "nincs igazam"
3. hozok linket, mert követelõdzöl
4. kijelented, hogy a link cáfol, mert a kutyák nemis intelligensek, mivel a nikben nincsen szó kutyákról.

csak ém a kutyákról jeveset állítottam, másfelõl a definíció pont azt tartalmazta, amirõl beszéltem.

ezt a folyamatot, amit mûvelsz, hívják játszmázásnak, mert belekötsz mindenbe, és amikor beégsz vele végül, akkor terelni kezdesz.

[SFIJ]

Idézet: Jakuza - Dátum: 2006. jún. 14., szerda - 23:32

SFIJ itt egy kicsit masrol beszeltem.
Viccnek szantam a mondandomat.
Tudod oblivion = felejtes tehat elfelejteni a boxosokat es nem a konzolra ertettem, ha erted.
Mindent tul komolyan vesztek.
A te dolgod mit csinalsz amugy sajat vagyonkaddal, ha neked az esik jol hogy Xboxozni, PCzni, Retro gepet gyujteni akarsz a te sajat dolgod.
Amugy sincs senkinek abba beleszolasa, hogy te mit tartasz helyesnek, addig a pillanatig ha masranezve nem serto a dolog.

nem akartam senkit megbántani, bocs. csak kissé szarevõvé váltam, már nem akarom minden pénzem informatikára költeni

[Jakuza]

Idézet: SFIJ - Dátum: 2006. jún. 15., csütörtök - 0:48

nem akartam senkit megbántani, bocs. csak kissé szarevõvé váltam, már nem akarom minden pénzem informatikára költeni

Nem is bantottal meg.
Nem erre akartam kilyukadni.
Hanem arra, amikor az elfogultsag miatt nem lat ki valaki a fejebol es a masikkal szemben nem latja a valos helyzetet.
Hibazni lehet, de elismerni is hibat megkellene tanulni.

Szerkesztette: Jakuza 2006. 06. 14. 23:55 -kor

[hvuk]

SFIJ!

A mesterséges intelligenciás topicban folytatom a vitát.

Szerkesztette: hvuk 2006. 06. 15. 00:09 -kor

[cx.core]

Idézet: SFIJ - Dátum: 2006. jún. 14., szerda - 22:19

- nagy generikus regfile. a reg file mérete elég régóta 128, ebbõl a register renaming mutogat annyit, amennyit az aktuális változat támogat.

Oké, nyilván ISA szemszögbõl értettem a dolgot; a register renaming csak az OoO-t segíti, a compilereinket nem.

Idézet

- egyszerû címzési módok/load store mûködés. ez a kezdetektõl támogatva volt

Itt sem arra gondoltam ám, hogy támogatjuk-e az egyszerû load/store utasításokat, hanem arra, hogy a memóriában turkászó ALU/egyéb utasításoktól, illetve a komplex címszámítási módoktól (ModR/M, SIB, disp, mint pl. [ebx+ecx*4+0xB0C1FA52] :Ð) megszabadulunk-e.

Idézet

-A szegmens reiszterek megléte nem az ördögtöl való, sõt kimondottan hasznos a mostanában divatba jövõ virtualizációs technológiákkal kapcsolatban. való igaz a lin/win megelégszik a lineáris címekkel.

A szegmensregiszterezés valójában (sok x86 sallanghoz hasonlóan) feature-nek álcázott csökevény. Már anno a 386-oson megjelent 32 bites védett módból ki lehetett volna hagyni. Az újonnan megjelent virtualizációs technológiák mind a lapozási mechanizmusba (illetve fölé) épülnek.

Kicsit úgy érzem, mintha a szemedben most léptem volna le a falvédõrõl, pedig nem.
Az IA32 védett módot kívül-belül ismerem, napi szinten kurkászom IA32 assembly kódot (fõleg a GCC kimenetét :Ð), stb.

Idézet

szóval lehet az x86-ot szídni, de egyvalamit ne feledj. megnyerte a RISC-ekkel szembeni háborút.

Félreértés ne essék, nem szidtam az x86-ot. Mindössze egy kérdést tettem fel az x86-64 architektúrák várható fejlõdésével kapcsolatban.

Idézet: Wikipedia

Removal of older features: A number of "system programming" features of the x86 architecture are not used in modern operating systems and are not available on AMD64 in long mode. These include segmented addressing (although the FS and GS segments remain in vestigial form, for compatibility with Windows code), the task state switch mechanism, and Virtual-8086 mode.

[SFIJ]

Idézet: Jakuza - Dátum: 2006. jún. 14., szerda - 23:54

Nem is bantottal meg.
Nem erre akartam kilyukadni.
Hanem arra, amikor az elfogultsag miatt nem lat ki valaki a fejebol es a masikkal szemben nem latja a valos helyzetet.
Hibazni lehet, de elismerni is hibat megkellene tanulni.

érem tehát konzolt venni eredendõ hiba, hogyismonjam, bûn?

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 0:14

Oké, nyilván ISA szemszögbõl értettem a dolgot; a register renaming csak az OoO-t segíti, a compilereinket nem.

itt két iskola van. az egyik aszondja kevés reg+ooo, ráadásul jó prefetch esetén az L1 D$ is kvázi regiszter file, a másik meg aszondja (itanium), tessék kitakarni az összes regisztert, kidobni az interpretert. jól látható, hogy az itanium koncepció is megbukni látszik az x86-tal szemben. én nem tom egyik mellé sem letenni a lándzsámat, nem látszik igazolva számomra, hogy böhömsok regiszter, nagyongyors mûködés.

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 0:14

Itt sem arra gondoltam ám, hogy támogatjuk-e az egyszerû load/store utasításokat, hanem arra, hogy a memóriában turkászó ALU/egyéb utasításoktól, illetve a komplex címszámítási módoktól (ModR/M, SIB, disp, mint pl. [ebx+ecx*4+0xB0C1FA52] :Ð) megszabadulunk-e.

mért kéne mexabadulni? Varietas delectat. ha nem szereted, ne használd abban igazad van, hogy ezen utasítások jelentõs része, például a stringmozugató obsolete, ezért ugyan megvan, de iszonyat lassú, másfelõl kiderült, hogy van egy részhalmazuk, ami nagyon jól kézreáll az SSE/MMX koncepicóhoz.

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 0:14

A szegmensregiszterezés valójában (sok x86 sallanghoz hasonlóan) feature-nek álcázott csökevény. Már anno a 386-oson megjelent 32 bites védett módból ki lehetett volna hagyni. Az újonnan megjelent virtualizációs technológiák mind a lapozási mechanizmusba (illetve fölé) épülnek.

Kicsit úgy érzem, mintha a szemedben most léptem volna le a falvédõrõl, pedig nem.
Az IA32 védett módot kívül-belül ismerem, napi szinten kurkászom IA32 assembly kódot (fõleg a GCC kimenetét :Ð), stb.

nem volt sértõ szándékom. abban igazad van, hogy a host-os-es virtualizációhoz nemnagyon kell, de van egy másik út, a meta-kerneles virtualizáció, ami önmagában több OS-t futtat. Jó példa erre az IBM VM/ESA. az ilyen rendszerek mindig szegmentált memóriájúak. nem állítom, hogy tömegesen használják ilyenre az x86-ot, de azért használják így is.

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 0:14

Félreértés ne essék, nem szidtam az x86-ot. Mindössze egy kérdést tettem fel az x86-64 architektúrák várható fejlõdésével kapcsolatban.

ez egy piaci igények vezérelte architektúra/ISA, úgyhogy ez a kérdés nagyon nehezen válaszolható meg. jelenleg nem látszik olyan bántó korlát, melynek feloldása valós piaci igényként jelentkezne.

[vers]

a nagy regiszterfile a nyerö, föleg kézi optimizálásnál, azzal lehet olyan kodot ini ami leturja az eget
az oooo fölösleges szarság, és a C optimizáciot is le kell tiltani, mert minden csak ront a jó kodon

[GI]

Idézet: vers - Dátum: 2006. jún. 14., szerda - 23:18

1 évre?  azért mit kell csinálni ?

Nemtom, én most 60%-on állok a figyelmesztetések tekintetében. Már eltiltva is lettem ki idõre.
Nemsokára elérem a 100%-ot és akkor valami great eltiltást kapok sokezer nappal, úgy emlékszem kb 5 év

[SFIJ]

Idézet: vers - Dátum: 2006. jún. 15., csütörtök - 9:48

a nagy regiszterfile a nyerö, föleg kézi optimizálásnál, azzal lehet olyan kodot ini ami leturja az eget
az oooo fölösleges szarság, és a C optimizáciot is le kell tiltani, mert minden csak ront a jó kodon

nah elre szokta elric aszondani, hogy egy nagyon jo optimakolo compiler az esetek eleg nagy szazalekaban hatekonyabb, gyorsabb kodot keszit, mint a kezimunka Amit az OoO-rol irsz az erdekes. en sokkal inkabb azt latom az amd es intel doksikban, hogy hogyan lehet esszel aladolgozni az OoO-nak ezek a dolgok nem az ordogtol valoak am. ezek tettek az x86-ot risc-verove

Szerkesztette: SFIJ 2006. 06. 15. 14:29 -kor

[SFIJ]

Idézet: GI - Dátum: 2006. jún. 15., csütörtök - 10:08

Nemtom, én most 60%-on állok a figyelmesztetések tekintetében. Már eltiltva is lettem ki idõre.
Nemsokára elérem a 100%-ot és akkor valami great eltiltást kapok sokezer nappal, úgy emlékszem kb 5 év

meglepo, hogy te a galamblelku hogy allhatsz 60%-on?

[vers]

Idézet: SFIJ - Dátum: 2006. jún. 15., csütörtök - 13:27

nah elre szokta elric aszondani, hogy egy nagyon jo optimakolo compiler az esetek eleg nagy szazalekaban hatekonyabb, gyorsabb kodot keszit, mint a kezimunka Amit az OoO-rol irsz az erdekes. en sokkal inkabb azt latom az amd es intel doksikban, hogy hogyan lehet esszel aladolgozni az OoO-nak ezek a dolgok nem az ordogtol valoak am. ezek tettek az x86-ot risc-verove

ja riscverövé  , ez igaz is összetákolt kodnál
amugy megértem a piac ilyetén alakulását, mert se idö se szakértelem nincs jo programot irni, átképzett programozok vannak sok helyen
még szerencse a konzolbiznisz másrol szol, ezért sem tudj lenyomni a pc a ps2-t se

Szerkesztette: vers 2006. 06. 15. 15:04 -kor

[SFIJ]

Idézet: vers - Dátum: 2006. jún. 15., csütörtök - 14:54

ja riscverövé  , ez igaz is összetákolt kodnál
amugy megértem a piac ilyetén alakulását, mert se idö se szakértelem nincs jo programot irni, átképzett programozok vannak sok helyen
még szerencse a konzolbiznisz másrol szol, ezért sem tudj lenyomni a pc a ps2-t se

nem biztos, hogy valami osszetakolt, csak lehet olyan hogy nem kompilalhato nyelven van megirva, hanem interpretalt. ez nem biztos, hogy hatrany. gondolj erre a website-ra, ami php+AB kezelo osszessege. ha egy ilyen szajtot nativ kodban szeretnel nagyon nagy bajban lennel. a legkisebb moddolas is egy hetig tartana, mig PHP szinten a szkriptet megcsocsalni 'riltajm' is lehet es mar elo is allt a valtozas. Ha a web nativ, kezzel optimakolt kodokbol allna,  akkor a web meg mais a 15 evvel ezelotti szinten allna. nota bene a modern game-ekben az AI nagyon sok esetben valamilyen interpretalt funkcionalis nyelvben, pl. haskell - van megirva.

Szerkesztette: SFIJ 2006. 06. 15. 16:07 -kor

[cx.core]

Idézet: SFIJ - Dátum: 2006. jún. 15., csütörtök - 17:03

nem biztos, hogy valami osszetakolt, csak lehet olyan hogy nem kompilalhato nyelven van megirva, hanem interpretalt.

Ebben az esetben nyilván az interpretert kell optimalizálni.

[GI]

Idézet: SFIJ - Dátum: 2006. jún. 15., csütörtök - 14:27

meglepo, hogy te a galamblelku hogy allhatsz 60%-on?

ááá, ne is kérdezd

igazságtalanság történt, pedig JOGOSAN anyáztam   :Ð

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 16:16

Ebben az esetben nyilván az interpretert kell optimalizálni.

egy interpretalt nyelv mindig dinamikus memoria-allokalalast, auto-allokalast es referenciaszamlalast takar. ez a tulajdonsag ellegge ellene ha sajnos az optimalhatosagnak.

[cx.core]

Idézet: SFIJ - Dátum: 2006. jún. 15., csütörtök - 9:24

abban igazad van, hogy a host-os-es virtualizációhoz nemnagyon kell, de van egy másik út, a meta-kerneles virtualizáció, ami önmagában több OS-t futtat. Jó példa erre az IBM VM/ESA. az ilyen rendszerek mindig szegmentált memóriájúak. nem állítom, hogy tömegesen használják ilyenre az x86-ot, de azért használják így is.

A szegmentált memóriacímzés az x86-on jelenlévõ formájában nem teszi lehetõvé több védett módú OS biztonságos futtatását egyazon gépen. Ehhez arra lenne szükség, hogy az egyes virtualizált gépek védett módjának 0. privilégiumszintjén futó kód számára is korlátozható legyen a fizikai memória bizonyos (más virtuális gépeknek kiosztott) területeinek elérése. Ezt az x86 szegmentált címzése nem teszi lehetõvé, mivel a 0. szinten futó kódnak (definíció szerint) "mindent szabad" (a deszkriptortáblázatokat írni, a szegmensregisztereket globális, "supervisor" típusú deszkriptorokra mutató szelektorokkal feltölteni, stb). Ilyetén virtualizációt a lapozás sem tesz lehetõvé (eredeti formájában), hasonló okok miatt (a 0. szinten futó kód módosíthatja a laptáblázatokat, feltöltheti a laptáblázat-címregisztert (CR3), stb).

A kívánt mûködés sokkal egyszerûbben kiváltható: minden virtuális gép kontrollblokkjába csak annyi információ kell, hogy a virtuális gép lineáris címterét hova kell leképezni a fizikai címtérbe (mondjuk a szokásos bázis+határ mezõkkel, a védett mód szegmensdeszkriptoraihoz hasonlóan). Nehogy rákezdd, tudom, ez definíció szerint a szegmentált memória. De ehhez nemhogy a virtuális gépekben "látható" szegmensregiszterekre, de semmilyen onnan "látható" regiszterre nincs szükség.

Tehát mégegyszer: nem azt állítom, hogy az említett rendszerek nem használnak szegmentált memóriát, hanem azt, hogy az x86-os szegmentált címzésnek ezekhez semmi köze.

Azért is tartom csökevényesnek, mert nem transzparens; a szegmensregiszterek minden szintrõl "láthatóak".

Idézet

ez egy piaci igények vezérelte architektúra/ISA, úgyhogy ez a kérdés nagyon nehezen válaszolható meg. jelenleg nem látszik olyan bántó korlát, melynek feloldása valós piaci igényként jelentkezne.

Megpróbálom összefoglalni, hogy mi vetette fel bennem a kérdést.
Ha megnézünk egy modern "complex" meg egy modern "reduced" ISA-t, akkor azt látjuk, hogy a nagy "összecsapás" során kölcsönösen tanultak egymástól. Pl. az x86-ba is bekerültek valamilyen szinten a másik oldal szívének szottya predikátumos végrehajtású utasítások (cmov, fcmov), vagy az a lebegõpöttyös összehasonlító utasítás, amely közvetlenül az ALU flageit módosítja (fcomi), nem az FPU-ban lévõket. De pl. az ARM procikba meg bekerült a Thumb utasításkészlet, amely a félszavas (:Ð) utasításaival nyilván az x86 drágaszágát, a nagyobb utasítássûrûséget hivatott megkaparintani. Ezek nyilván kiragadott példák csupán (ráadásul a saját szájízem szerint válogatva), de az x86-64 bõvítéseivel együtt nézve számomra egyértelmûen radikálisabb változásokat jeleznek elõre. Ki tudja, talán még azt is megérjük, hogy a TLB miss az eljövendõ x86-64-eken is egyszerûen csak megszakítást fog okozni, ahelyett, hogy a laptáblázatok HW-es bogarászása indulna meg.

Szerkesztette: cx.core 2006. 06. 15. 19:41 -kor

[vers]

minden fölösleges szart ki kell szorni a procikbol és növelni a végrehajto egységek számát
csak  vectoros végrehajtoegységeket bele ,  128 vagy 256 biteseket
ugy hogy a amikor nem vector kod fut a végrehajtoegységek szétválnak és 2, 4 vagy 8 thread egyidejü futását engedélyezik , amikor vectorutasitáshoz ér leállitja az összes többit
esetleg egy utasitáselörejelzés mehet bele az nem olyan sok 256 bites  egységeknél

Szerkesztette: vers 2006. 06. 15. 20:51 -kor