[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

[SFIJ]

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

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).

igen ez a mai latasmod mellett mar igaz, csakhat volt/van ring0,1,2,3 1985-ben a szegmentalas meg divatban volt, vagyis az ibm koncepicoja, mikoris a meta-os egyeb OS-t tolt (IPL), ring 0-n laknak a virtualis szervizek, amikbol minden OS gazdalkodhat. Az OS a Ring1-re toltodik. Ha megnezed a linux IBm VM/ESA specifikus kernel reszeit, akkor valami ilyesmit latsz. Namost a budos helyzet az lett, hogy
a) nem tudta/akarta az intel a meat OS funkciokat letrehozni, itt ugye DOS, CP/M 86, xenix (kesobb sco unix)-rol volt szo
b) az allando kapuhivasok doglassuva tettek a mukodest
c) a 90-es evek elejeig az ment, hogy volt ugye a microsoft fele DPMI, ami egy katasztrofa ugye, mert nem igazi dolog, hanem valami olyasmi, hogy belepsz IA32 modba, kihuzatod a szegmenseket 4Gigara, van egy flat cimed, a RAM-ok birjak ameddig vannak, mikozben van egy EMM386.sys ami lenyegeben egy kapuhivas, es lapozgat neked memoriateruleteket, tovabba valoban szetszegmentalja fizikailag a virtualis dos gepeket. ennek a legokosabb implementacioja a quterdeck fele desqview volt, ami DOS-okat es ratoltott proggiat tudott valoban multitszk futtani, igaz a proggik kozott zerus interakcio, adatcsere lehetett.
d) jott linus torwalds meg az NT, amik lenyegesen kisebb igenyuek voltak (privilegizalt mod + lapozas)
e) A szegmens regiszterek koruli oromkodes az utobbi 4 evben aranykorat elte, PSE36, felfedeztuk ujra az EMS-t igaz mostmar valos 32 bites proggik szamara, ambator eletveszelyes dolog felhasznaloi program kezebe adni a memoria-kezeleset.

A virtualizacio sokkal primitivebb modon lejezelheto amugy, wmvare modra. a guest OS kernel futas kozben tabornokvedelmi hibakat okoz, amit egy, a host OS-be injektalt virtualis driver egyszeruen elkap, es leemulalja a priviliegizalt funkciokat.

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

hehe igen, de meg tudom oldalni, hogy minden garazda csak a sajat szegmens regisztereit lassa, es ne lathasonn bele a masikeba

lenyeg ami lenyeg. az AMD azert hagyta el az AMD64 modbol a szegmens reisztereket, mert
a) a kutyanak sem kell
b) noveli a cimszamitas indirekcios szintjeit ezaltal lassitja a mukodest.

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

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.

ebben teljesen igazad van, az ISA-k olyanna valnak, amilyenre szukseg van. A SUN USIII-nak van olyan utasitasa, ami a regiszter file-ban ropteben leszamol egy 8x8-as (i)DCT-t. Egy ilyenre a leg elvetemultebb CISC-fanok is elgedetten csettinetenek a szajuk szelen a nyelvukkel

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

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.

Ennel en kisebb igenyu vagyok. nekem mar azis jol esne ha a regiszterek beteges harmassaga mexunne, ugymint egesz regiszter, lebegopottyos regiszter, xmm regiszter. legyenek csak 128 bites memoriacellak es az hogy a benne levo adatot hogyan kell ertelmezni az kizarolag a raapplikalt utasitas dontse el.

[cx.core]

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

A virtualizacio sokkal primitivebb modon lejezelheto amugy, wmvare modra. a guest OS kernel futas kozben tabornokvedelmi hibakat okoz, amit egy, a host OS-be injektalt virtualis driver egyszeruen elkap, es leemulalja a priviliegizalt funkciokat.

Igen, ilyet már volt szerencsém látni egész közelrõl. Ennek szerintem annyi a szépséghibája, hogy sajnos van olyan x86 utasítás (smsw), amellyel akármelyik szinten futó kód megtudhatja (mivel nem okoz kivételt), hogy védett módban van-e a processzor. Tehát lehet olyan kódot írni, amely csak valós módban hajlandó elindulni, ezért aztán a VMWare-nek beletörik a bicskája. Azt persze lehet, hogy ezeket az utasításokat futtatás elõtt megpróbálja felderíteni, de hadd ne mondjam, hogy ezeknek az elrejtésére x86-on hányféle mocskos kis trükk létezik.

Én egyébként a virtualizációs megoldások közül a teljesen SW oldalit preferálom, amit az exokernelek meg az L4-like mikrokernelek ún. "LibOS" megközelítése képvisel.

Idézet

hehe igen, de meg tudom oldalni, hogy minden garazda csak a sajat szegmens regisztereit lassa, es ne lathasonn bele a masikeba

Gondolom lokális deszkriptortáblázatokkal. De ehhez is az kell persze, amit fentebb írtál.

Idézet

lenyeg ami lenyeg. az AMD azert hagyta el az AMD64 modbol a szegmens reisztereket, mert
a) a kutyanak sem kell
b) noveli a cimszamitas indirekcios szintjeit ezaltal lassitja a mukodest.

Ez világos, és szerintem jó húzás volt.

Idézet

Ennel en kisebb igenyu vagyok. nekem mar azis jol esne ha a regiszterek beteges harmassaga mexunne, ugymint egesz regiszter, lebegopottyos regiszter, xmm regiszter. legyenek csak 128 bites memoriacellak es az hogy a benne levo adatot hogyan kell ertelmezni az kizarolag a raapplikalt utasitas dontse el.

Ezt, látod, ki is hagytam, pedig általában ezzel szoktam kezdeni, amikor sorolom, hogy mit szeretnék Karácsonyra.

[SFIJ]

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

Tehát lehet olyan kódot írni, amely csak valós módban hajlandó elindulni, ezért aztán a VMWare-nek beletörik a bicskája.

ebben igazad van, de ez kvaz 16 bites uzemmodot jelent, ezeket a windows jelenleg vagy a dos emulaciojan vagy a wovexec-en keresztul futtatja (korai win kodok). Ha ezek sem valnak be, akkor megprobaljuk a wmvare-t. ha mindez kudarcot vall, akkor a szoffert hasznalhatalannak nyilvanitjuk es eldobjuk. illetve nem. akkor marad a BOCHS, ami egy telejesen szofferes x86 emulator, es inditaskor konfigolhato hogy milyen ISA-t emulaljon A BOCHS-sel, amikor nagyon muszaly volt, futtatam sun ultra 5-on nativ win9x szoftokat, (offisz 97)

[cx.core]

Idézet: SFIJ - Dátum: 2006. jún. 23., péntek - 17:04, AMD Hammer - negyedik rész

az OOP szofferek sajnos katasztrofalisan rosszul parhuzamosithatoak. mindezek mellet nagymeretu index-tablakat igenyelnek (virtualis metodusok) igyha elhajgyjuk az IA32-bol az indexelt cimzesi modokat, annak bizony ara van.

Az eredeti témafelvetésem célja éppen az lett volna, hogy nézzük meg az említett változási lehetõségeket mindkét szemszögbõl. Mi szól ellene (azon kívül persze, hogy maga a változás ellene van az x86 filozófiájának )? Mi szól mellette? Melyik esetében lehetséges, hogy egy technológia, programozási paradigma, stb. jövõbeni megjelenése/megerõsödése meg fogja követelni?

Sebaj...

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 23., péntek - 17:01

Az eredeti témafelvetésem célja éppen az lett volna, hogy nézzük meg az említett változási lehetõségeket mindkét szemszögbõl. Mi szól ellene (azon kívül persze, hogy maga a változás ellene van az x86 filozófiájának )? Mi szól mellette? Melyik esetében lehetséges, hogy egy technológia, programozási paradigma, stb. jövõbeni megjelenése/megerõsödése meg fogja követelni?

Sebaj...

cx.core nemtok erre valaszolni. ma az ipar java es c# kodot akar es szeretne irni. ezek oop, sot meg rosszabb, mert interpretalt, heap-buzi, managed adatstrukturaval rendelkezo nyelvek, ahol az adatok elettartama nem tervezheto, hanem fire-and forget elvu, es a garbage collector megmajd eldob mindent ami eldobando. az ilyen szoffer olyan kodot eredmenyez mmi rosszul parhuzamosithato, es a load/store architekturak szamara is agyrem.

a kozeljovo az ilyen interpretalt nyelvek burjanzasat hozza majd, meg persze masodviragzasnak indultak a funkcionalis nyelvek is.

ezekkel a trendekkel csunyan szembepisil mindaz, amerre a processzorok fejlodese hat. najo pontositok. a processzorgyartok rajottek, hogy nagy penz van a szorakoztato iparban, igy az ilyeten igenyeket elegitik ki leginkabb manapsag. csak ez a boom is lassan veget er...

Szerkesztette: SFIJ 2006. 06. 23. 17:38 -kor

[d n . r]

Most olvastam egy hírt, amirõl eszembe jutott ez a nyitó hozzászólásom:

Idézet: dnr - Dátum: 2004. jan. 3., szombat - 1:18

(Mielõtt ebbe belevágnék, pontosabban meghatároznám, mit értettem fentebb elkülönült alatt: nem mást, mint hogy a hardvert (esetünkben a processzort) pontosan ide és nem máshová fejlesztik. Ez egyben azt  jelenti, hogy ennek a piacnak kell eltartania a fejlesztés roppant tetemes költségeit!)
És hogy ezt miért kérdõjelezem meg, arra a grafikus chip-ek piacáról hozok analógiát. Jelenleg úgy néz ki, hogy a professzionális kártyák piacát is az ATI és az nVidia uralja, méghozzá úgy, hogy a profi kártyákat pontosan ugyanazokra a chipekre építik, mint amikre a kommersz (azaz nagy tételben eladható, tömegesen gyártott) kártyák épülnek.
(Két zárójeles megjegyzés. Egyrészt van még a 3DLabs, azonban a tulajdonos a Creative, és múlt tavasszal fel is röppent, hogy a P10re gémer kártyát IS kivánnak építeni (aztán nem lett belõle semmi, valszeg mert nem lett volna elég a teljesítménye a gémer piacon. Viszont emlékeim szerint lett belõle "kommersz" multimédia-verzió). Kérdés, mit hoz itt a jövõ.

Na, hát már nem kérdés:

https://www.hwsw.hu/hirek/32521/3dlabs_crea...processzor.html

Idézet

A 3Dlabs aztán idén tavasszal azt közölte, hogy elhagyja egykori vadászterületét, a professzionális videochipek piacát és a jövõben a mobil eszközök számára kíván megoldásokat fejleszteni. A cég szerint a multimédiás és 3D alkalmazások futtatására képes hordozható eszközökben, például tenyérgépekben és okostelefonokban sokkal nagyobb a piaci potenciál, mint a professzionális munkaállomásokban. A vállalat nemrég kezdte meg elsõ mobil terméke, a DMS-02 nevû lapka próbagyártását.