Názory k článku Technologie grafických stanic firmy SGI

Ta část o problémů SMP je opravdu výstižna. Mimochodem, proč se dneska používaji technologie Dual Channel pro přístup do paměti? No hlavně proto, že každý processor má jaksi „blíže“ ke svému kanálu. O duplikování stránek z jednoho bloku paměti do druhého se stará operační systém. To je taky asi důvod, proč v nových OS (Win 7 apod) jsou pracovní sady všech aplikací 2× větší, než normálně.

Onehdy jsem programoval řadič pro plánování paralelních úloh. Centralizovaný řadič jsem byl nucen nakonec přepsat na distribuovaný řadič, protože to (i do budoucna) poskytovalo lepší výkonost. Prostě každý procesor měl vlastní frontu úloh a pokud úloha generoval další úlohy, tak si je zařazoval do své fronty. Pouze v případě, kdy mu „došla práce“ prohledal fronty ostatních procesorů a z nich si vytáhl další práci. V ideálním případě se hlavní úloha rozpadla na N procesorů hned na začátku a pak už to mezi sebou komunikovalo minimálně.

No nevim jak je to na Intelu, ale pokud se pamatuju tak na AMD Dual channel znamena jen 2* vetsi sirku sbernice. Jadra jsou uvnitr chipu beztak pripojena na spolecnou L3 cache.

To co pisete spis pripomina nekolik fyzickych CPU propojenych pres hypertransport linky (coz jsou velmi rychle seriove linky). AMD to ma tak ze kazdy rekneme 4jadrovy CPU ma vlastni RAM a pak nekolik tehle linek pomoci nihz komunikuje s ostatnimi CPU. Cely to probiha bez ucasti programatora (nemusim tedy psat prikaz posli blok dat na CPU 4). Misto toho je pamet kazdeho uzlu teto site namapovana do spolecneho fyzickeho prostoru a radice pameti a HT linek se staraji v hodne presmerovani pozadavku na cteni/zapis. Takze je to podobny jako u SGI.

Nevím, takhle mi to bylo řečeno obchodníkem s počítači. Víc jsem nezjišťoval, takže možná je to kec. Nicméně mi bylo taky řečeno že jsou dvojjádrové procesory se společnou cache a ale s vlastní cache. Tak nevím.

Každopádně to k těm NUMA stejně spěje.

AMD K8 a Intel i7 _JE_ NUMA, takze nespeje, ale je.

PS: Jo, kupoval jsem AMD tříjádrový (což je vlastně čtyřjádrový, kdy jedno jádro je vadné) a hypertransport byl zmíněn v prospektu.

Dual channel neznamena, ze by „kazdy CPU mel bliz ke sve pameti“, ani „jen 2× vetsi sirku sbernice“.

Dual channel jsou dva nezavisle radice, ktere muzou kazdy delat neco jineho (nebo muze byt crossbar switch v CPU nakonfigurovany na jejich „tupe“ prokladani). Naopak neni pravda ze by treba jadro 0 melo bliz k radici 0 a naopak. Aspon u AMD je to symetricke.

Cili jeden AMD procesor neni NUMA. Vicesocketovy system uz ale NUMA je.

-Yenya

Nechtěl jsem tvrdit, že AMD je NUMA, protože jak jsem pochopil u NUMA jde o to, že na uzlu je plnohodnotný procesor včetně všech potřebných řadičů, kdyžto tady jsem chápal, že je výhodou dual channelu je, když je paměť uspořádána tak, že se procesory nebijou na jedné paměti, kdy operační systém plánuje přidělování procesoru a paměti tak, aby oba řadiče jeli současně, každý „na svým“. Nemusí to být tedy tak, že by to bylo přiděleno na tvrdo, ale prostě při přístupu jednoho procesoru do jednoho kanálu má druhý procesor přístupný druhý kanál bez čekání, nebo musí počkat.

Optimalizace na straně OS … pokud vím, od té doby, co mám AMD s dual channelem pozoruju, že WIndowsy hrozdně neradi přehazují jednovláknovou úlohu mezi procesory, na starších vícejádrech, kde byla obyčejná paměť to nehrálo roli a tam se mi nestalo, že by jeden procesor jel na 100% a druhý na 0%, ale že oba jeli zhruba na 50%. Na AMDčkach je to běžný jev. Pochopil jsem, že se plánovač zařazuje procesy tak, aby se maximálně vyhnul situaci, kdy oba procesory musí přistupovat současně na jeden kanál. Mám pocit, že WinAPI snad dokonce na to má atribut na proces, tuším „ideal processor“. Podle něho pak plánuje a vybírá stránky fyzické paměti na alokaci či přiswapování.

Jen jestli to neni spis updatovanymi windowsemi. Neustale prehazovat 1 proces mezi 2ma jadry je
hloupost at mate jakykoliv radic pameti. Vede to neustalemu vyprazdnovani a naplnovani cache. Jestli se to takhle opravdu chovalo a ted se jiz ne, tak spis to byla nejaka chybka windowsu kterou po case opravili a automaticky nainstalovali novou verzi pres windows update, nebo jak se to jmenuje.

Tvrzení, že se o duplikování stránek stará operační systém mně připadá, pardon, uhozené.
Bavíte se doufám o dnešní PC architektuře, kde se provozuje symetrický multiprocesing – procesory pracují nad společným paměťovým prostorem a z pohledu programátora musí toto být transparentní. Nějaké přesuny a komunikaci musí řešit hardware, jinak si to nedovedu představit – jak by třeba byla zajištěna kompatibilita se staršími SMP OS? To by jako na takovém stroji běžely jen s jedním CPU a s poloviční RAM?

Soucasne systemy jsou budto SMP, nebo cc-NUMA. Coz znamena, ze programator nejakou neuniformnost pameti resit nemusi, nechce-li. Cili operacni system ani programator se skutecne nemusi starat, ze ktereho NUMA uzlu zrovna ma pridelenou pamet.

Na druhe strane dost pomaha, pokud OS o NUMA topologii vi a vyuziva teto znalosti. Linux napriklad mel (na SGI Altixech, nevim jestli je to v upstreamu) moznost stranky textu jadra mit duplikovane ve vice NUMA uzlech, protoze se predpokladalo, ze nejaky kod jadra obcas vykonava kazdy NUMA uzel. Nebo treba alokator pameti se snazi pridelovat procesu prednostne ty stranky pameti, ktere jsou nejbliz procesoru, na kterem dany proces bezi.

Nevim o tom, ze by soucasne OS delaly nejake cilene presuny jiz naalokovanych stranek smerem k uzlum, ktere ty stranky nejvice vyuzivaji. To uz by vyzadovalo kristalovou kouli srovnatelne sily, jaka je potreba pro zjisteni, kterou stranku ted zrovna odswapovat :-)

-Yenya

Po skusenosti z linuxom a windowsom na X3650 M2 zo zapnutou NUMA architekturou. Linux o NUMA vie a (IMAO) ju aj vyuziva. Hlavne mu vadi ak nie su jednotlive pametove uzly rovnake. Taky windows serverXY sa tym nejak netrapilm a vobec mu nevadilo ze jeden socket nemal „vlastnu“ pamet.

SMP stroj ma spolocnu pamet. taky IBM X326 (ak si to dobre pametam cislo) ma polku pemetovych socketou pouzitelnych len ked je tam druhe puzdro. Inak ich neuvidi NIK, ani bios.

Origin 2100 (rok dodani 2000, 2 GB RAM, 8 CPUs) mame jako hlavni studentsky server, a az letos ho se slzou v oku nahrazujeme za novejsi.

Jinak procesory MIPS maji spoustu zajimavych vlastnosti, o kterych by se dalo mluvit, napriklad:

– nema instrukce pro praci se zasobnikem – proste se jen jeden obecny registr „dohodou“ vyhradi jako ukazatel zasobniku, a instrukce typu PUSH, POP se rozpadaji na LOAD/STORE a inkrement/dekrement toho registru

– CPU muze byt nabootovana v big-endian nebo little-endian rezimu (kdysi existovaly dve binarni verze Linuxu pro MIPS podle endianity).

– CPU neumi delat nezarovnane pristupy do pameti (x86 umi, ale je to pomale a stoji to hodne kremiku), takze treba LOAD dvoubajtoveho cisla z liche adresy vyvola vyjimku (IRIX ji pak reportuje jako SIGBUS).

SGI (a dnes vlastne vsechny NUMA systemy) pouzivaji variantu „cc-NUMA“ (cache-coherent), coz znamena, ze programator se nemusi starat o koherenci pameti v jednotlivych uzlech. Funguje to zhruba tak, ze sice jeden radek cache muze byt na vice NUMA uzlech, ale jen pokud ty uzly jen ctou. Pokud nekdo chce zapisovat, musi se podivat jestli zapisuje nekdo jiny (pokud ne, staci jen vsem ostatnim prislusny radek cache zneplatnit a je mozno zapisovat). Tohle ovsem dela HW, nikoliv programator.

To ze je procesor primo navrhovany pro NUMA systemy se da vyuzit i v dalsich vychytavkach. Treba na x86 se zamky (spinlocky, semafory, …) delaji pomoci atomickych instrukci (LOCK, CMPXCHG, …). Na MIPS je mozne zamek udelat napriklad tak, ze procesor udela obycejny LOAD a STORE, jen potom programator muze testovat, jestli mezi LOAD a STORE nedosel pozadavek na zneplatneni (cili jiny procesor zapisoval). A pak pripadne muze LOAD/STORE sekvenci opakovat. Tohle je pekne, ze to vubec nikde nezamyka sbernici, a na rozdil od x86 se takto na sbernici netlucou libovolne dve „atomicke“ instrukce, ale jen ty, ktere opravdu sahaji na ten stejny zamek.

Kazdopadne ale diky za clanek.

-Yenya, http://www.fi.muni.cz/~kas/blog/

Zajímavé vlastnosti.

Dneska je zásobník nutností už proto, že to není jen fronta čísel ale je to hlavní součást vlákna… třeba jak jsou realizované skoky a návraty? Jistě, určitě to lze udělat uložením adresy do (simulovaného) zásobníku a dlouhým skokem a návrat skokem na adresu v zásobníku. Ale to už mi přijde jako trošku velká onanie.

CPU klidně může omezovat přístup na nezarovnané adresy. Povolování jako u x86 je spíš problém než výhoda, protože samotná vlastnost ničemu nepomůže a jen to napomáhá tvorbě kódu, který je neprenosný (tzv. medvědí služba programátorům). Naštěstí se na x86 tohle dá také zakázat a pak generuje výjimku

x86 postupně (doufejme) dospěje k zamykání na úrovni stránek. Už teď se doporučuje používání interlocked operací omezovat, protože to zdržuje a mnohem jistější je používat protokol acquire a release (tam kde je podporován). Nicméně dřív nebo později to dojde k zamykání stránek a potvrzování, že zápis nebyl v konfliktu.

Největší problém je při návrh knihoven pro řešení těchto věcí. Techniky pro jednu platformu nelze používat v jiné platformě a kolikrát to znamená redesign celého systému.

Naopak delat to takhle mi prijde lepsi, protoze je to obecnejsi a HW jednodussi. Na ARMu je takhle vlastnost taky. Kazda skokova instrukce ma ve svem operacnim kodu `L-bit', kterej kdyz je 1, zpusobi ze adresa nasledujici instrukce se pri provadeni skoku presune do tzv. Link-registru. To je uplne normalni register, ktery se da pouzivat na vypocty, pokud zrovna nedrzi adresu navratu. Obvykle se pak tento registr ulozi na zasobnik az ve volane funkci (na to je instrukce STMDA ktera umi ulozit podmnozinu registru kterou si clovek vybere pomoci bitove masky — takze 1 instrukci se ulozi navratova adresa i registry ktere by funkce jinak prepsala a jeste se dekrementuje ukazatel zasobniku, coz neni fixni registr ale dalsi parametr te instrukce, takze zasobniku muzu mit vic, kdybych to potreboval)

Vyhoda je takova, ze funkce ktere uz dal nic nevolaji nemusi tenhle registr davat na zasobnik, coz usetri trochu prenosu po sbernici.

Krom toho je CPU jednodussi protoze nemusi mit explicitni instrukce PUSH, POP a CALL.

Me to prijde celkem elegantni. Jeste jsem zapomel dodat ze navrat z funkce se provadi instrukci LDMIB, ktera vyzvedne registry opet podle masky a inkrementuje ukazatel zasobniku.
Tim ze misto link registru v masce uvedeme program counter (nebo jak se na intelu rika instruction pointer) tak se tim provede navrat z procedury.

Takže je to vlastně totéž. Vedle jednoduché instrukce skoku s ukládáním do registru a následné ukládání registru existuje poměrně komplikovaná funkce ukládání registrů do zásobníku.

Pro CISCovou strukturu jasně vítězí rozdělení na JMP a CALL/RET. PUSH a POP je vlastně jen obezlicka, aby člověk nemusel ukládat přes MOV na adresu [ESP] a pak ho inkrementovat/de­krementovat.

Pro RISCovou strukturu bych podporu zásobníku vůbec neviděl a skutečně jen jump s uložením instrukčního pointeru… třeba do registru, to už je v celku jedno.

Ale samozrejme na MIPSu je normalni kompilator C a normalne se pracuje se zasobnikem. Jen ten zasobnik neni z hlediska CPU neco specialniho, s cim by se pracovalo vyhrazenymi instrukcemi. Coz povazuju za prudce elegantni.

Podobne konstrukce (registry vyhrazene v ABI platformy pro nejaky specialni ucel, i kdy sam procesor je povazuje za bezne registry) se vyuzivaji casto. Treba registr gp v IA64, ktery se pouziva pro optimalizaci volani funkci v lokalnim modulu (vizte Intel Itanium Software Conventions & Runtime Architecture Guide).

-Yenya

aisa jde na plastiku? ;-)

O MIPSech i dalsich typech RISCovych procesoru vyjde samostatny clanek, uz to davam dohromady. Ta instrukcni sada je opravdu velmi jednoducha a instrukce jsou navrzeny tak, aby se provadely s minimalni „spotrebou“ kremiku, psat na MIPS prekladac musi byt urcite mnohem jednodussi nez na x86 (i kdyz x86_64 uz je na tom lepe).

Jinak MIPS zdaleka neumira, spis naopak – pred par (?) lety si na MIPSove jadro koupily patent i cinske firmy a dava se do ruznych embedded zarizeni. I tento prispevek velmi pravdepodobne prosel pres nejake routery apod. s MIPSem.

Zdravim z FOSDEMu :-), kde se mj. docela diskutovalo o ARMech a MIPSech.

Trochu mimo.
Mám SGI Octane2 (R14000)

Řešil někdo, jak na tuhle mašinu dostat linux?

Bacha, nejde mi o to, jak na SGI/Octane dostat linux, to umím (deian si mi tiše ševelí na nádherným SGI O2), ale jak to dostat na Octane2 s tímhle cpu

Jde o to, že Octane2 ma R14000 a všechny netbooty pro IP30 co jsem zkoušel, jsou jenom pro R10000–12000 a 14000-untested.
Zkoušel jsem ip30-r10k±20050530.img, ip30-r10k±20050820.img a nějaké starší a všechny se sekaj.

Je mi toho SGíčka líto, přeci jenom 2×600MHZ, 2G RAM, to je docela škoda a Irix je pro mě nestravitelnej (a navíc desetkrát deně se sekne)

pokial irix pada – tak je nieco spatne v kompe nie v irixe – pri akych prilezitostiach sa to sype?

Aka je momentalne podpora O2ky v linuxe – dokaze to aspon grafiku?

ten irix je prostě rozdrbanej a já nemám chuť to dávat do kupy. Už jenom instalace přes O2 je vopruz. Řešení vidím jedině v linuxu. NEERGONOMIE irixu mě doslova vytáčí a s aplikacemi na úrovni roku 2003 se toho taky moc dělat nedá.
Jinak podpora O2 je ok, grafiku mám v 1280×1024/15bit (bohužel na 60Hz na CRT, připojit LCD není tak jednoduchý, protože potřebuju LCD se synchr. na zelenou a takové nemám). Jedou scsii disky, síť… prakticky všechno. Nerozchodil jsem jenom grabovací kartu (ale ta mi popravdě nechodila ani pod irixem).
Samozřejmě taky nemaká 3D, ale to je mi jedno, protože je to stejně plečka a přebije to nejlevnější PC.
Hlavním problémem je ram (mám jenom 256M). Dal bych si mokrým hadrem přes hubu, když si vzpomenu, jak se u nás 10 O2 vyhazovalo na kontejner a já debil si nenahamtil ramku.

To by me taky zajimalo.

Vlastne by me zajimalo i jak tam dostat IRIX, mam jen holy HW bez disku. Zkousel nekdo spustit IRIX urceny pro O2 na Octane2 tak ze by jen blok po bloku zkopiroval disk?

Mam takove tuseni ze by to nemuselo jit ani z O2 na O2, vzhledem k tomu chipu se seriovym cislem co v sobe O2 ma (a nepochybuju ze ho ma i Octane2).

Irix zainstalovany na O2 nepojde spustit na octane ani nahodou. Hlavne dovody su jednoduche O2 je UPLNE ina platforma ako Octane – bola vsak vyvynuta tak aby bola binarne kompatibilna. O2 dokonca pouziva 32 bitovy system zatialco octane ma 32/64bit. V O2 systeme nieje ani mnozstvo ovladacov na HW ktory pre octane je – napr ultra160 SCSI radic do PCI… Dalej Octane si zainstaluje verziu grafiky (MGRAS/ Vpro) hned pri instalacii. dokonca aj pri vymene je treba preinstalovat nejake balicky atd…

System z O2 na O2 skopirovat ide – takmer bezproblemov oblubeny sposob je xfsbump/ xfsrestore chvilku to poskrka a mas tam vsetko vcetne /dev a podobnych pakarni. Podrobne o tom http://www.sgidepot.co.uk/disksfiles.html#CLONE .

Seriove cislo v O2 je dolezite koli PCI rozsireniu – tie sa nesmu prehodit (to znamena ze motherboard a PCI musia byt zhodne) lebo inak system nenabootuje. Vsetko ostatne je len upgrade.

Jen pro zajímavost:
moje Octnae2 nemá CDROM, takže instalace (IRIXu) se musí dělat tak, že se při bootu skočí do monitoru, vybere se vzdálená instalace a CD se strká do jiný mašiny.
Jenže filsystem CD je pro stand. PC (Lin/Win) nečitelný, takže tou vzdálenou mašinou musí být stejně zase SGI. BBBBBBBBBBRRR­RRRRRRRRRRRR

Naštěstí pro linux stačí udělat někde DHCP/BOOTP/TFTP a bootnout jádro ze sítě, pak už standardní síťová instalace (třeba debianu, nebo gentoo)…teda když se zadaří (viz můj dotaz nahoře).

mínusem Linuxu je 3D akcelerace
plusem jsou mnohem větší možnosti, state of the art jádro&aplikace… já už bych se k irixu nezvracel

No jo ja som ale SGI vzdy chcel hlavne koli 3D akceleracii a namakanym grafickym moznostiam. Popravde linux mi bezi na mamkinom kompe a ked potrebujem nieco fresh tak to spustim z neho…

Pre irix existuje nekoware – mnozstvo roznuch GNU/ GPL programov portovanych na IRIX niektore su sice trochu starsieho data ale zvecsa stacsia.

Jo cd filesystem pre sgi je tusim EFS alebo tak niec je to dohladatelne na nete – a tusim to ma podporu aj v linux kerneli, takze tolko ku STRAAASNEMU SGI tkore pouziva neexistujuci FS ;)