Názory k článku Grafické karty a grafické akcelerátory (24)
-
Pavel TišnovskýZlatý podporovatelJeště v některém z dalších dílů popíšu architekturu Sun Ray, to je ve své podstatě framebuffer navěšený na Ethernet :-) Ale je pravda, že se staršími grafickými systémy od SGI (ale i od Sunu a dalších "mrtvolek") nemám žádné zkušenosti, takže by to bylo opisování z cizích materiálů (tím však nevylučuji, že se tím nebudu zabývat, zatím jsem však vycházel ze svých pracně nasbíraných poznámek). -
jirka b. (neregistrovaný)Moc pekne, na neco podobneho jsem dlouho cekal. Ale mam trochu problem - snazil jsem se ten "Stellar GS2000" priradit ke konkretnim workstationum nebo obchodnim nazvum SGI grafik (treba podle http://sgistuff.g-lenerz.de/hardware/graphics/index.html) a vubec se mi to nedari. Muzete to, prosim, nejak upresnit?
Taky mi vrta hlavou ten "Power Iris" - znam Personal Iris a Professional Iris (coz je vsechno prelom 80. a 90. let minuleho stoleti), ale "Power Iris"? Mozna to mely byt "PowerSeries", ale stejne nevim, ke grafickemu subsystemu ktereho stroje bych mel Vas popis priradit. Ale hledam vubec spravne?
Technologie NUMA se mi naopak zda byt docela nova (pulka 90. let?), ale Vami uvedene stroje (Origin) zrovna moc pracovni stanice nejsou - myslim, ze Octane (vicemene to je Origin 200, ale s grafikou, pokud se nepletu) nebo Onyx by byl asi lepsi priklad.
V souvislosti se SGI technologiemi je mozna zajimave, ze graficky subsystem, ktery byl ve starych Personal Irisech, se dodaval (asi jen kratce) i do IBM PC pod nazvem IrisVision. Dokonce pry existuje i ovladac teto "grafiky" pro AutoCAD a Win 3.x. Viz napriklad: http://www.4crawler.com/IrisVision/index.shtml nebo http://www.walshcomptech.com/ohlandl/video/Iris.html -
Pavel TišnovskýZlatý podporovatelTen nazev Power Iris se pouziva v souvislosti s pracovnimi stanicemi "POWER IRIS Graphics Supercomputing Workstation", blize viz napriklad stranka http://www.futuretech.blinkenlights.nl/powerseriestech.html. Pravda je, ze to asi nebude oficialni nazev, SGI to totiz vsechno prezentuje pod Power Series.
GS dvoutisicovka se vsak dala pouzit i v dalsich typech superpocitacu (napriklad jako graficky front-end na stolech uzivatelu), u SGI pro to udelali nejaky obecny typ sitoveho propojeni (podrobnosti vsak nevim, me vzdycky zajimala hlavne ta "graficka" cast a ne cele zelezo).
Ano, NUMA se vyvijela nekdy pocatkem devadesatych let. V zadnem pripade si nemyslim, ze by to byla "stara" technologie, naopak je to jedna z mala veci, co dneska drzi SGI nad vodou, protoze s tim maji velke zkusenosti.
Onyxem se, spolu s Infinite Reality2, budu zabyvat v dalsim pokracovani tohoto serialu. Nevim, jestli popisu i Octany, to byly, alespon z pohledu SGI "normalni" pracovni stanice - na jednom jsem jeste pred cca tremi roky pracoval ve skole, pak se mu vysypal zdroj a nikdo to nechtel za tech cca 20 tisic opravit :-( [zijeme ve veku PCcek]. -
jirka b. (neregistrovaný)> viz napriklad stranka http://www.futuretech.blinkenlights.nl/powerseriestech.htm
Vida, link na kamarada Iana ;-) Tak to jsem necekal..
> GS dvoutisicovka se vsak dala pouzit i v dalsich typech superpocitacu
No prave. Vygoogloval jsem par odkazu, ale nic z toho nebylo SGI a to me docela zmatlo.
Takze asi bude problem priradit tuhle vec konkretnimu vyrobku od SGI. Da se nekde najit fotka toho GS2000 nebo nejakeho stroje, kde se tahle vecicka vyskytovala?
> ... NUMA ... naopak je to jedna z mala veci, co dneska drzi SGI nad vodou
To vim. Vlastne ani netusim, ktera dalsi jejich technologie je dneska jeste "zajimava", kdyz pouzivaji grafiky od ATI, procesory od Intelu,...
> Onyxem se, spolu s Infinite Reality2, budu zabyvat v dalsim pokracovani tohoto serialu.
Uz se tesim.
> Octany ... na jednom jsem jeste pred cca tremi roky pracoval ve skole
Zavidim. U O2 (coz je "jeste normalnejsi" stanice, ale ne tak zajimava jako Octane) sedim zrovna ted, ale Octane jsem vzdycky videl jen z dalky. -
Pavel TišnovskýZlatý podporovatelVida, to jsem nevedel, ze se znate. Snad se aspon vysvetlil ten matouci nazev.
O GS2000 jeste zkusim neco najit, mam to vsechno doma na ofocenych papirech, Google se kupodivu nechyta :-o
NUMA je dneska opravdu drzi a potom asi jeste nejake patenty (a ze jich budou mit - trosku me mate ta souvislost s nVidii, jak to maji pravne doreseny). Je to skoda, SGI byl - alespon pro grafiky - vzdycky pojem, podobne jako Cray, ktery pred nejakou dobou spolkli. Ten "pad" znacky je videt take v odbornych casopisech. Drive se prakticky vsechny testy grafickych algoritmu delaly na nejakem referencnim stroji od SGI (O2, Octane), dneska je to nejake PC-cko (vetsinou znackove, ale to dneska nic neznamena). Ale co, Sun je na tom v podstate stejne, podobne jako Apple :-)
Musim priznat, ze ten Octane je z dnesniho pohledu uz pomaly, ale v dobe, kdy se porizoval, to bylo opravdove delo. Mimochodem, diky pripojovani 3D scanneru, ktery si jaksi moc nerozumel z SCSI jsem dokonce nekolikrat zazil bootovani Octana :-), jinak to jelo po celou dobu, co jsem ho pouzival (cca tri roky) bez vypnuti :-) -
jirka b. (neregistrovaný)Obcas jezdim do Edinburghu, kde Ian bydli (a skladuje i svoje SGI - treba Crimsona a Onyx v garazi ;-)
Jinak myslim, ze Sun je na tom porad jeste relativne lepe (stale vyvijeji stroje aspon s vlastnimi procesory i kdyz grafiky maji myslim uz hodne davno od ATI). O Apple skoda mluvit. Ale HP nebo IBM se v pracovnich stanicich ostatne take moc nelisi od prumeru a ostatni skoncili uz driv :-(
Jak je to s nVidii, to by me taky zajimalo - obcas se povida, ze v nVidii je dost lidi prave ze SGI a take jsem slysel, ze GeForce grafiky snad vychazely ze zkusenosti s RealityEngine od SGI. Ale opravdu by me zajimalo, co je na tech recech pravdy. -
Pavel TišnovskýZlatý podporovatelNojo, já takové známé se šrotem v garáži nemám (asi proto, že nemám ani tu garáž :-). Teda v Anglii dělá docenta Alan Chalmers (má rád česko, díky pro něj výhodným cenám pitiva :-), ale u nich v Bristolu asi už přešli kompletně na PCčka :-)
Osobně si myslím, že Suny drží nad vodou jejich tak trochu nechtěné dítě - Java. Pokud by tento jazyk (tj. derivaci C++) vytvořil někdo jiný, asi by neměl ze začátku šanci (pamatujete ty jejich reklamní kampaně ještě v dobách Java 1.0 :-) s hrozným AWT a zabugovanými knihovnami?). Je škoda, že potopili ty Javovské procesory, možná by s nimi nakonec uspěli, ostatně Net Computer není špatný nápad (viz X-terminály a Sun Ray). Servery vyrábí, to je pravda, ale už se začíná postupně prolínat OS: Linux=>Sun servery, Solaris=>PC, takže to možná i v serverech za pár let zabalí a budou je dělat na platformě Intel (to mě dost vadí, protože to zase vyhraje strašně pitomá architektura - registry, sběrnice, centralizovaný CPU...).
Právě že jsem četl, že nVidii založili lidé z oddělení SGI grafických karet. SGI to prý dost poškodilo a zdrželo další vývoj grafických akcelerátorů. Ale stejně to museli (ti přeběhlíci :-) nějak vykoumat, že je nikdo nezažaloval za porušení patentů, doložky o nekonkurování (či jak se to u nás jmenuje) apod. -
Pavel TišnovskýZlatý podporovatelNo, vlastně ano. To co uživatelé získají za velmi nízkou cenu samozřejmě zase ztratí tím, že využívají neefektivně napsané programy (ale s tím se nedá nic dělat, taková je prostě architektura). Nehledě na to, že to pro většinu obyvatelstva vypadá líp, když mají dejme tomu AMD 1800MHz a ne Power PC 500MHz. Taky rychlosti všech zařízení v PC (HDD, CPU, paměť, síťovka a grafika) se jaksi vytratí, když se najednou všechna zařízení rozhodnou současně přenášet data :-).
To mě zajímá, jak dlouho s sebou ještě potáhneme to pitomé rozhodnutí IBM použít pro první IBM PC šestnáctibitové procesory od Intelu a ne třicetidvoubitové Motoroly 68k. Kde by dnes byla Motorola a kde Intel (asi by si navzájem prohodily market embedded zařízení a PC :-) a zejména kde bychom byli mi programátoři, kteří musíme stále zápasit s těmi šestnácti bity (kolik stovek tisíc hradel je potřeba, aby procesor uměl virtual 8086?). -
S tim se neco delat da. Teda, ne s tou architekturou, ale vetsina dnesnich programu obsahuje i vetsi neefektivity nez ty dane architekturou - krome toho si uvedom, ze napriklad tebou zmineny V86 mod NIJAK neovlivnuje rychlost behu programu prelozeneho pro normalni mody (napr. i386 protected nebo amd64).
S tou sbernici je to horsi - ne v pripade pameti, ta uz je pripojena jinak, ale napriklad HDD a sitovka se casto perou o pomerne uzke misto ... nekdy i s grafikou.
Mozna kdyby IBM pouzila motorolu, jeste porad by pocitac stal 200 000,-. Tezko rict, jak moc by i treba pouhych par centu ceny PC navic zpomalilo jejich rozsireni - mozna jen o mesic, mozna o 10 let ... Vic by me zajimalo, kde bychom byli kdyby IBM nezastavila vyvoj OS/2.
Jestli jako programator dneska zapasis s 16 bity, zajimalo by me co delas. Normalni programatori sice porad zapasi s nedostatkem registru (skryte, je to jedna z pricin pomalosti programu), ale ostatni nedostatky je uz netrapi, i ta neortogonalita instrukcni sady je z vetsi casti vyresena.
Kolik stovek tisic hradel ... nevim. Netrapi me to. Faktem je, ze uzivatele zbytecne plati za mozna i ctvrtinu procesoru, ale je to presne to o cem jsem mluvil - tato suma se ztrati ve sleve za hromadnou vyrobu. -
Pavel TišnovskýZlatý podporovatelad první odstavec)
naprostý souhlas.
ad druhý odstavec)
Mám dojem (ale můžu se mýlit), že ta cena byla +- stejná. O volbě procesoru rozhodovaly nějaké kšefty s bublinovými paměťmi, které se - ó jaká ironie - nakonec ani moc nerozšířily. Více bylo uvedeno v dokumentu "Great Processors Past and Present", zkus si ho někde vyGooglit :-) [kdyžtak můžu poslat].
Se šestnácti bity jsem dlouho zápasil (a skrytě zápasím dodnes) na Windows 95 a Windows 98. Teoreticky jde sice o třicetidvoubitové systémy, ale handle jsou pouze šestnáctibitové, ale i další věci, například souřadnice při kreslení. Zajímavé je, že NT tímto neduhem netrpí.
A kde je problém? Třeba v tom, když vytvořím HTML stránku s tabulkou, kde chci mít políčka editovatelná (tj. zobrazená jako TextBoxy). V Internet Exploreru s tím problém kupodivu není, ten si GUI vykresluje sám nezávisle na GDI (!). Ale ve FireFoxu a tuším i v Netchcípáku se pro GUI používalo GDI, takže počet všech GUI prvků dohromady (všechny otevřené aplikace i samotný Explorer) jich můžou použít 65535 (NULL nejde :-). No a při větších tabulkách to Windows 95/Windows 98 samozřejmě neunesou a pěkně jdou do kytek (většinou ani nezobrazí chybový dialog, neb ten také využívá GDI :-))).
Já vím, řešení je nepoužívat editovatelné tabulky, ale když oni uživatelé chtějí, aby se Intranetové aplikace chovaly jako Excel :-), a v tomto s nimi souhlasím.
ad poslední odstavec)
pravda, doby, kdy se využil i poslední tranzistor jsou dávno pryč. Viz třeba nedokumentované instrukce na mnoha procesorech (Z80 a spol.), kde se využívaly i instrukce zadrátované na okraji čipu (teď strašným způsobem zjednodušuju, prosím nechytat za slovíčka). -
Pavel TišnovskýZlatý podporovatelJeště k tomu GDI - tady nezáleží na velikosti operační paměti. Jde udělat aplikaci, která využije všech cca šesesát tisíc handlů GDI a zabere přitom pár kilobytů paměti - stačí GDI alokovat a případně i vykreslovat v nekonečné smyčce :-). Takže nákup další paměti s tímto problémem nepomůže.
btw: problém s GDI má například WinCVS, ale vcelku nechápu proč (ani jsem to blíže nezkoumal maje command line cvs :-). -
Pavel TišnovskýZlatý podporovatelWindows 95 mi ani tak nevadí, ale Windows 98 má stále spousta uživatelů a jen tak je za nic nevymění :-). Zdrojáky oken samozřejmě nemám, tak nevím, proč jsou ty handly šestnáctibitové, ostatně i čísla zpráv a parametry aplikace při spuštění jsou v W95/W98 třicetidvoubitové (proto se to také jmenuje wParam a lParam :-), takže nevím, proč něco převedli a něco ne.
Ta chyba se teoreticky může projevit i u souborů a dalších "resourců", ale pouze u GDI je to podstatné, protože kdo si naráz otevře 65k souborů :-) -
Mas pravdu, jaky normalni program by si potreboval najednou otevrit vic nez 2k souboru ... teda kdyz nepocitame tu moznost ze je neotevira najednou, ale jen zapomina zavrit, jako tla alias gnu-arch ... :-)
K 64k jsem se jeste nedostal. Ono i ty 2k staci, kdyz default limit na pocet souboru je 1024 ... jesteze jen soft. -
Mikulas Patocka (neregistrovaný)> krome toho si uvedom, ze napriklad tebou zmineny V86 mod
> NIJAK neovlivnuje rychlost behu programu prelozeneho pro
> normalni mody (napr. i386 protected nebo amd64).
To ovlivnuje --- pri kazde instrukci, co pristupuje do
pameti, se musi k adrese pricist bazova adresa segmentu.
Vsecky soucasne operacni systemy tuto adresu nastavuji na 0,
je to uplne zbytecne (segmentace v 32-bitovem modu je
nepouzitelna), ale holt se ta bazova adresa stale musi
pricitat, protoze Intel mel pri navrhu 286 a 386 velky voci. -
No dobre, nechytej me za slovo, tak trochu ovlivnuje ... jenze
1) Segmentace v 32-bitovem modu je pouzitelna a nelze vyloucit, ze by ji Intel udelal i tak. Pravda, v 16-bitovem modu je nevyhnutelna.
2) Jsem si jisty, ze toto pricteni rychlost programu neovlivnuje, protoze se provadi v HW a tedy paralelne. Mozna kdybys zlikvidoval celou segmentacni jednotku, nejakeho urychleni bys dosahl, jenze narozdil od bazove adresy bez atributu segmentu (CPL, DPL ...) se neobejdes.
3) Mozna ze kdyby vsichni nemysleli v konvencich jazyka C, slo by napsat prostredi ktere je naopak diky segmentaci rychlejsi - protoze ma jednodussi relokaci. Jenze to by vyzadovalo delsi pointery ... a rozhodne by to nebylo ku prospechu debugovani. -
Pavel TišnovskýZlatý podporovatelNa druhou stranu má flat adresovací prostor taky nevýhody (kromě jednoduchosti adresování, zde se prakticky vracíme k COM-ům :-). Pokud je mi známo, tak na Windows i Linuxu je stále možné spouštět kód uložený na zásobníku nebo v datové oblasti. Zakázání této featurky (oddělením adresových prostorů a vynulováním jednoho bitíku v deskriptoru) by se projevilo ve větší odolnosti systémů vůči útokům.
-
Mikulas Patocka (neregistrovaný)Zakazat spoustet kod na zasobniku nepomuze proti nicemu
(leda script-kiddies pouzivajici predpripravene utoky).
Utocnik si totiz na ten zasobnik muze ulozit treba adresu
funkce exec, za to pointer na retezec "/bin/sh" --- a uz ma
roota, a nemusel z datoveho segmentu pustit nic. (eventualne,
pokud utoci vzdalene, tak tam prida jeste neco jako
-c "nc -l -p 2000|sh").
Ochrana zasobniku je lepsi delat pres strankovani (to uz
AMD-64 umi). Oddeleny adresni prostor na zasobnik by moc
dobre nefungoval, protoze C musi byt schopno jednotne
pracovat s ukazatelem do dat i do zasobniku. -
Pavel TišnovskýZlatý podporovatelPokud se používá chrootované prostředí, tak mu ten exec nepomůže. Ale pravda, na toto jsem při psaní příspěvku nemyslel, měj jsem na mysli vložení strojového kódu na zásobník s jeho spuštěním, třeba při returnu (stejně jako v případě toho execu).
Proč musí C-čko jednotně přistupovat do zásobníku i adresového prostoru? Vždyť šestnáctibitové překladače to nijak neomezovalo. (tady mi asi něco uniká, ale pokud C-čko používá pouze klasický stack frame, tak ten může být IMHO kdekoli). -
To si pis ze to 16bitove prekladace omezovalo. Jde o to, ze pokud chces odlisne pristupovat k zasobniku a k datum, musis si do pointeru poznamenat co za pripad zrovna on je (coz vetsinou vede na pointery delsi nez int) a musis byt schopny vyresit vsechny pripady libovolne komplikovanych operaci na pointeru provadenych - uvedom si, ze pointer+pointer-pointer je platny C vyraz (dobre, mozna potrebuje zavorky). V C si nemuzes dovolit vyhodit vyjimku kdyz to nejak nepujde, protoze C zadne vyjimky nema.
-
Mikulas Patocka (neregistrovaný)Pokud nema shell, muze na ten zasobnik klidne postupne dat
adresy funkci socket, bind, listen, accept, mmap, read i
s parametry, a nahrat si do programu kod jaky chce. Musi dat
stridave adresu nektere teto funkce libc a pak skok na exit
point libovolne funkce (s dostatecnym mnozstvim lokalnich
promennych), ktery pouze posune esp nahoru, cimz odstrani
argumenty predchoziho syscallu, udela ret, cimz skoci na
dalsi syscall.
Z tohoto duvodu nebyli patche na nespustitelny zasobnik
zahrnuty do linuxu. I kdyz to jde udelat i na obycejne 386
--- proste se zmensi limit CS, zatimco DS, ES, SS se nechaji
bez limitu. Kdyby to do kernelu dali, tak utocnici zacnou
pouze vyrabet odlisne exploity, bezpecnost se nezvysi, a
pouze bude spousta zbytecneho kodu v jadre.
Ty pointery v 16-bitovych programech skutecne omezovaly.
V C totiz musi jit napsat
int globalni_pole_v_datovem_segmentu[10];
void f()
{
int lokalni_promenna_na_zasobniku;
int *ukazatel;
...
ukazatel = &globalni_pole_v_datovem_segmentu[3];
...
ukazatel = &lokalni_promenna_na_zasobniku;
}
V 16-bitovych prekladacich Borland se to resilo tak, ze
existovaly ruzne modely --- tiny (kod+data < 64k)
small (kod 64k, data 64k) medium (kod 64k, data 640k)
compact (kod 640k, data 64k), large (kod+data < 640k) ---
a cim vetsi model, tim vic dat to mohlo adresovat, ale zase
to pak delalo nahravani segmentovych registru, takze to bylo
pomalejsi. -
Pavel TišnovskýZlatý podporovatelAha, na pristup do zasobniku pres ukazatele jsem nepomyslel (asi proto, ze jsem to nikdy nepotreboval), ale uznavam, ze i toto musi jit prelozit - s tim, ze zrovna nekde tady starsi prekladace bugovaly, protoze nektere lokalni promenne davaly do registru.
Stary Borlandi prekladace (2.0 a 3.1) si pamatuju - bylo to moje prvni prostredi, kde jsem s C-ckem delal. V modu TINY jsem par programku udelal, protoze to byl jediny rezim, pri kterem se daly vygenerovat COMy - vsechny segmentove registry odkazovaly na stejny segment. Ale neumelo to nahodou u MEDIUM a LARGE adresovat vic pameti? K tomu Borlandu prece dodavali nejaky sestnactibitovy DPMI, tusim DPMI16B.OVL nebo tak nejak. Jeste jsem tam nekdy volal sluzby HIMEM.SYS (ty znam jiz od dob ASM), ale to je dost nesystemove a musi se porad myslet na to, ktera stranka je prave aktivni - takove rucni ovladani swapu :-)
Fakt je, ze kdyz jsem se zasekl na problemech s large array apod. (jde to resit i v Borlandech, ale hnusne a stejne to delalo chybky), tak jsem presel na GCC a bylo... -
Sestnactibitove DPMI ti sice rozsiri celkovou pamet nad 640kb, ale nutnosti priserne pointerove aritmetiky se nezbavis, naopak, bude to s ni jeste horsi.
Ano, HIMEM.SYS je dobre akorat tak na swapovani do pameti. Kdyz chces neco poradneho, musis uz pouzit VCPI nebo DPMI - nejlepe 32bitovou verzi - a idealne 32bitovy flat model :-). Nevim, jestli to nejaky prekladac pod DOSem umel driv nez DJGPP, a to je vlastne GCC ... -
Pavel TišnovskýZlatý podporovatelJa vim, nehlede na to, ze zrovna to Borlandi DPMI bylo dost zabugovane - ostatne jako cele to vyvojove prostredi (coz je zajimave, protoze na stejnem stroji fachcil Borland Pascal bez nejmensich problemu - asi je to stejne jako rozdil mezi Delphi a Borland C++).
Presne to jsem si pri praci s HIMEM.SYS pomyslel a hned jak to bylo mozne (tj. nainstaloval jsem si GCC/DJGPP), tak jsem se Borlandu zbavil. Flat mode nemel tusim ani Watcom, ale s tim jsem delal jenom chvilku. Jeste byl nejaky dobry prekladac, co zacinal na Z (Zortech?), ale o nem vim jen to, ze je v nem napsany Vivid :-) -
Ano. Hlavnim duvodem, proc tomu tak stale je, je takzvana trampolina - zvyk gcc (a patrne i jinych prekladacu) ukladat na zasobnik kratke kusy kodu napriklad pro obsluhu signalu. Na odstraneni se pracuje. Jakmile bude hotovo, jsou dve reseni jak zvednout odolnost systemu - no-exec bit strankovaci tabulky (Moderni procesory tuto sikovnou vecicku uz maji. IMHO ji mela mit uz i386, ale asi se na ni nedostalo.) a snizeni nejvyssi spustitelne adresy zkracenim code segmentu (Tim se zabrani nejvetsimu problemu - zasobniku. Na spousteni dat to moc nepomuze.)
Oddeleni adresovych prostoru by pochopitelne bylo rovnez resenim a Intel to tak puvodne myslel, ale jak uz jsem rekl malokdo je ochotny smirit se s pointerem delsim nez integer a dvakrat pomalejsi pointerovou aritmetikou. -
Mikulas Patocka (neregistrovaný)To pricitani bazove adresy segmentu se neprovadi paralelne.
Ten procesor musi byt schopen: dostat z predchozi instrukce
neznamou adresu, pricist k teto adrese segmentovou bazi,
(udelat vyhledani v L1 cachi a paralelne v TLB), porovnat
tagy a dat vysledek pro dalsi instrukci.
To vyhledani v L1 cachi a TLB jde paralelizovat, protoze
strankovani ti nezmeni dolni bity adresy ale segmentace uz
je zmenit muze.
Tohle vsecko trva 2 - 4 tiky. (Pentum3 - 3tiky, Duron - 3tiky,
Pentium 4 verze < 3 - 2tiky, Pentium 4 verze >= 3 - 4tiky).
Kdybys tam tu bazi segmentu odstranil, asi bys tomu pomohl.
Na AMD-64 uz segmentaci nastesti vypli.
Pouzivat efektivne segmentaci nejde, protoze nahrati
segmentoveho registru je 8 - 26 tiku a tohle delat pri
kazdem pristupu na pointer nejde. -
Nemyslel jsem doslova paralelne, ale paralelne ve smyslu proudoveho zpracovani dat. Tj. pochopitelne nejde zaroven jednu adresu hledat v TLB a segmentovat, ale predpokladal bych ze jde hledat jednu adresu v TLB a jinou segmentovat.
Krome baze musis testovat limit a prava segmentu.
Na AMD-64 rikaji, ze segmentaci vypli. Ve skutecnosti vypli limit pro vsechny registry (testuje se pouze kanonicka forma, to je snadne protoze staci bitovy test), bazi pro CS,DS,ES a SS a atributy pro vse krome CS. Registry FS a GS stale pouzivaji bazi a az budu mit 64bitovy nasm tak si schvalne zkusim jestli je pristup pres FS pomalejsi nez pres DS ...
Od toho ma procesor 4 datove segmentove registry - nebo mluvis o tom ze to nestaci ? No, mozna mas pravdu ... vetsina programu ma podstatne vic sdilenych knihoven a rozumna alokace segmentovych registru by pro prekladac byla pekna fuska. -
Mikulas Patocka (neregistrovaný)Jo, je to pipelinovany tak, ze se zvladne jeden pristup do
pameti za tik (na AMD dokonce 2, pokud jsou do stejne radky).
Ale pri konstrukcich typu "struktura->polozka1->polozka2->polozka3"
nebo "k=a[q];i=b[k+l]" tu pipelinu nevyuzijes a pak kazda
dereference trva par tiku.
A v tom prvnim pripade, kdybys chtel pouzivat segmentaci,
bys musel 4x nahrat segmentovy registr, protoze nevis, do
jakyho segmentu ty pointery pujdou (trochu by to slo urychlit,
kdybys novou segmentovou cast pointeru porovnal s existujicim
segmentovym registrem a nahral ho pouze v pripade, ze se lisi).
--- ale i nacteni segmentoveho registru je
1(pentium 3, duron) - 7(pentium 4) tiku.
Pak je dalsi moznost programovat v jinym jazyce nez C, kde
by u kazdyho pointeru bylo receny v jakym ma byt segmentu,
ale takovej jazyk asi neni. -
Pavel TišnovskýZlatý podporovatelIntelove uz to pred nejakym casem rozsirili na 6 segmentovych registru (FS a GS), ale mimo DOS se tim opravdu nema cenu zabyvat :-) - a budme tomu radi.
-
Pavel TišnovskýZlatý podporovateljo sorry, blbe jsem si to precetl... To vyuziti stejne hodnoty v segmentovych registrech Borlandi pouzivali, ale prave ze jen v nekterych pametovych modelech, kde to bylo predepsano a jeste se to muselo potvrdil v Optionech. Taky jsem pouziti CS a SS pro jine ucely, nez pro ktere byly navrzeny, zatim nevidel, ona zmena CS do datove oblasti by asi moc dobre nedopadla :-) Videl jsem to vsak naopak - na zasobnik se hrabalo nejenom pres SS, ale i pres ES.
-
Mikulas Patocka (neregistrovaný)Co se tyce OS/2 --- nevidel bych to tak ruzove.
OS/2 je od pocatku navrzeno tak, ze je to jednouzivatelsky
system bez ochrany pristupu a s tim, ze chyba v jedne
aplikaci muze shodit cely system. (navzdory tomu, ze IBM o
nem tvrdi, ze ma CrashProtection(tm) technologii).
Primo pristupem na
nepovolenou adresu to nejde --- to OS/2 spravne sestreli
pouze dany program --- ale OS/2 ma sdilene knihovny vcetne
sdilenych dat mezi procesy, a pokud ta sdilena data jeden
proces poskodi, spadnou vsecky procesy, co danou knihovnu
pouzivaji. Daji se takto napriklad sestrelit vsecky procesy,
co pouzivaji TCP/IP. Kdyz se jedna o data GUI, tak holt
nezbyva nez restartovat cely system. -
Mikulas Patocka (neregistrovaný)Jeste k te OS/2 --- to, ze se OS/2 nevyviji, ten system
v podstate zachranilo (nez z marketingoveho --- ale
z uzivatelskeho hlediska). Kdyz se nevyviji, tak se do nej
nezavlekaji bugy.
V dobe nejvetsiho vyvoje OS/2 (verze 3) to byla hruza.
Krabicova verze OS/2 3 v sobe napriklad mela bug, ze kdyz
clovek soucasne pristoupil na disk i disketu, tak system
zatuhnul a musel se resetovat. Dalo se to obejit tak, ze se
pouzil ovladac disku, ktery pouzival bios int 13, ale ten
byl zase dost pomaly --- takze si clovek pri bootu musel
vybrat konfiguracni soubor podle toho, zda chce disketu a
pomaly disk nebo rychly disk bez diskety. Dalsi neuveritelny
kix --- vyrobil jsem program, co alokoval spoustu pameti
(vic nez fyzicke pameti --- aby se swapovalo), zapisoval tam
vzorek a cetl ho zpet a kontroloval, zda nebyl porusen. Po
nejake chvili ten vzorek porusen byl. (na win3.1 bez patchu
(byly vubec nejake?) tento program bezel a swapoval
libovolne dlouho bez chyby)
Za delsi dobu nevyvoje a pouheho opravovani bugu se takove
veci odstranily, a dnes je uz OS/2 s poslednim fixpackem
stabilni. Ale kdyby se IBM rozhodla do nej pumpovat dalsi
penize na vyvoj, asi by to dopadlo takhle nejak podobne
spatne. -
snehulak (neregistrovaný)spis se ukazuje ze ta kvalita neni tak hrozna a s dalsimi verzemi se zlepsuje ne ? kdyz si porovnate uzivatelskou zakladnu WIN a proverenost s OS/2 a presto tam byly takove brutalni chyby ? Budme radi ze to dopadlo jak to dopadlo, ze PC ma prakticky kazdy kdo chce a ze k Windows mame alternativu Linux. Mi to pripomina jak muj kamarad fanaticky amigista obhajoval ten OS amigy a potom sem mu ukazal 10 clanku jak prasacky to byl napsany system. Jenze kdo by si nekopl do billa :)
-
Mikulas Patocka (neregistrovaný)Mne network computer prijde jako uplna pitomost. Potrebuje
to totiz jednu vec --- spolehlivou sit. Porad je mensi
pravdepodobnost, ze se pokazi stolni pocitac, nez ze se
pokazi stolni pocitac nebo kabelaz nebo switche nebo server.
Kdybych musel treba v 10 vecer volat spravci domu, aby sel
nahodit spadlou sit, ze potrebuji programovat, asi by z toho
nebyl stastnej ani on ani ja.
Java je jazyk pro pitomce a z toho taky tezi (kdyz si clovek
nedokaze udelat poradek v navrhu kodu a nevi, v kterem bode
programu jsou ktere struktury platne --- potrebuje garbage
collection, ktera to cele nekolikanasobne zpomali). -
Pavel TišnovskýZlatý podporovatelNa práci doma bych NC taky nechtěl, ale pro podnikové systémy je to IMHO nejjednodušší a nejlevnější řešení. Vždyť dneska je situace taková, že uživatel pracně nabootuje v práci svůj stroj (takže má hned o nějakých 100-200MB paměti méně) a potom provozuje celý den tři-čtyři aplikace - většinou intranetové, alespoň v lepších podnicích :-). A správce celý den lítá a záplatuje systém atd. a to celé kvůli těm několika aplikacím. Nehledě na to, že někteří lidé (zejména šéfové) mají neodolatelné nutkání si všechno ukládat na lokální disk, který si samozřejmě, na rozdíl od serveru, nezálohují :-)
Jo, Java programátora od některých věcí odstiňuje, ale to dělají do určité míry všechny vyšší programovací jazyky :-) Sám ji nemám moc v lásce, vždyť to opravdu není nic jiné než trošku dynamičtější C++ - v té dynamičnosti ostatně vidím jednu z jejích hlavních výhod, kromě ohromného množství dostupných knihoven a některých vychytávek typu root object a interface. GC není jediná věc (na ten nadávat nemůžu páč to poprvé zavedl Lisp :-), je to také ochrana paměti (viz útoky typu přetečení zásobníku) a sandbox. -
Mikulas Patocka (neregistrovaný)I v te firme muze spadnou server a vysvetlovat v teto
chvili uzivatelum, ze se k zadnym datum nedostanou, asi by
byli nastvani. Takhle aspon muzou editovat dokumenty, co
maji na lokalnim disku, eventualne si je vymenovat na
usb-klicenkach, cili ta informacni struktura neni
paralyzovana uplne. S NC je tam jediny bod, ktery kdyz
spadne, tak spadne vsecko.
Co se tyce Javy --- kdyz clovek pise aplikaci pro jednu
firmu, tak je furt levnejsi koupit silny server a prumerne
programatory v jave. Kdyz se pise program, co si ma koupit
1000 lidi, tak je neni mozno vsecky nutit, aby si treba na
editaci dokumentu kupovali mnohoprocesorovy super-stroj.
Proto se tady java nepouziva. V C(++) se taky da psat bez
buffer overflowu, kdyz si clovek dava pozor, ale to vetsina
programatoru nedava :-( Ja jsem do linksu udelal buffer
overflow na halde pouze jednou --- napsal jsem tam
if (!(alokovana_velikost & 256)) udelej_realloc... ... a
melo tam byt 255. Nastesti se to nedalo zneuzit vzdalene. -
Pavel TišnovskýZlatý podporovatelKdyž spadne server, tak se stejně k žádným datům (které jsou většinou v databázi) nedostanou :-). Asi sis všiml, že mnoho věcí v IT se centralizuje, takže například po pádu Cisca je odřezáno například 12/24/36... uživatelů - to se starým koaxem neplatilo (ten měl za jiné problémy). Z mých zkušeností mohu říct, že největší problémy jsou ve větších firmách opravdu na straně klientských počítačů, ať už se jedná o "ztracené" soubory, tak o instalaci antivirů, záplat pro různé programy atd. A to už nemluvím právě o USB-klíčenkách, disketách, CD-ROMech a soukromých noteboocích - hodně firem tyto věci vcelku pochopitelně zakazuje a částečně tak dělá z klientských počítačů NC, akorát to ještě není dotažené k dokonalosti :-) (zůstává tam HDD). Server je většinou dost dobře zálohovaný a pokud nenastane opravdu velký průser (výpadek proudu tak dlouhý, že to nevydrží UPS, HW problém apod.), tak si prostě běží a nikdo o něm vcelku neví :-)
-
Pavel TišnovskýZlatý podporovatelOni se opravdu v minulosti chteli prejmenovat (ci na chvili dokonce prejmenovali). Bylo to v dobe, kdy obecne objem dodavek serveru a grafickych pracovnich stanic klesal a SGI se chtelo prezentovat jako dynamictejsi (?) internetova firma. Dokonce o tom psali v nekterem ze starsich cipu ve clanku venovanemu prave SGI. Zkusim o tom dohledat nejake dalsi informace.
ČLÁNKY DO MAILU