15.8.2006 00:34
David Ježek | skóre: 83
| blog: Mostly_IMDB
Rozbalit Rozbalit vše Re: Jaderné noviny - 2. 8. 2006
Portál AbcLinuxu, 29. dubna 2024 08:43
Aktuální verze jádra: 2.6.17.8. Citát týdne: Linus Torvalds. Marcelo Tosatti předává štafetu jádra 2.4. Filtrování SCSI příkazů. Diskuze o Reiser4 - znovu. Rozhraní pro jaderné události. Nová jádra a staré distribuce.
Aktuální předverze je 2.6.18-rc3, vydaná 29. července. Přísun patchů se zpomaluje úměrně s tím, jak začíná být nová verze stabilní. Takže tato předverze přidává několik oprav, ale nic moc navíc. Podrobnosti jsou v dlouhém changelogu.
Od vydání -rc3 bylo do hlavního repozitáře začleněno přes 100 oprav.
Aktuální -mm strom je 2.6.18-rc2-mm1. Mezi nedávné změny patří velká aktualizace x86-64 a NFS a spousta oprav.
Tvrdím, že rozdíl mezi špatným a dobrým programátorem je v tom, jestli považuje za důležitější svůj kód nebo datové struktury. Špatní programátoři se starají o kód. Dobří programátoři se starají o datové struktury a jejich vztahy.
Marcelo Tosatti oznámil vydání jádra 2.4.33-rc3, které obsahuje jen pár patchů. Zároveň dal na vědomí, že správcovství jaderné řady 2.4 přebírá Willy Tarreau, který již nějakou dobu připravoval sérii patchů "hotfix" pro 2.4. Marcelovi, který řadu 2.4 spravoval od verze 2.4.16, patří velký dík.
Pálení dat na CD nebo DVD je komplikovaný proces, při němž se používá velké množství SCSI příkazů. Takže každá aplikace, která vypaluje disky, musí mít schopnost posílat mechanice speciální SCSI příkazy. Těsně před vydáním jádra 2.6.8 se však vývojáři rozhodli, že aplikacím by nemělo být dovoleno posílat jakékoliv SCSI příkazy. Některé z těchto příkazů by mohly vést k přepsání firmwaru mechaniky, vznícení nebo nahrazení hudebních stop nahrávkami zpěvu Richarda Stallmana. Ve snaze zabránit těmto nežádoucím věcem začlenil Linus na poslední chvíli patch, který uživatelům bez dostatečných práv zakazoval posílat SCSI příkazy, jež nebyly na seznamu povolených v jádře.
Je skoro jisté, že žádný uživatel nezničil CD mechaniku jádrem 2.6.8. Jen málo z nich vůbec mohlo zapisovat na disky; filtrování bylo tak přísné, že uživatelé bez práv nemohli dělat nic užitečného. Pozdější aktualizace to napravily a s 2.6.10 už zase vypalování většině uživatelů fungovalo.
Ne však všem uživatelům. Jak nedávno poznamenal Dave Jones v konferenci linux-scsi, filtrování příkazů pořád působí potíže některým mechanikám Plextor. Utilita cdrecord se pokouší posílat těmto mechanikám speciální příkazy daného výrobce, ale jádro je nepustí. Všechno se zastaví a uživatel musí práci začít znovu jako root. Dave se ptal: nebylo by vhodné přidat k filtrovacímu kódu možnost výjimek pro příkazy specifické u různých výrobců?
Vývojáři blokového subsystému reagovali tak, že by se mělo prostě vyhodit celé filtrování příkazů. Tato funkce byla projednávána na nedávném setkání (storage summit) a účastníci se shodli, že by měla být odstraněna. James Bottomley shrnul:
Dovolíme-li uživatelům vypalovat CD, není možné je kontrolovat bezchybně, jak ukazuje tento případ. A když povolíme příkazy výrobců, určitě se najdou takové, které zformátují disk nebo zničí firmware...
Takže myslím, že je lepší vyhodit tu tabulku a přiznat, že nenabízíme žádné zabezpečení, než předstírat, že nějaké máme.
Vůči filtrovacímu kódu je několik výhrad. Jde o zápis pravidel do jádra, což všeobecně nebývá kladně přijímáno - i když v tomto případě jde vlastně o pokus rozlišit přístup k disku v mechanice a k mechanice samotné. Seznam příkazů nikdy nebude dokonalý. Vypadá to, že některé mechaniky potřebují slyšet speciální zaklínadla od výrobce, jinak odmítnou na disk zapisovat. Některé příkazy mají na různých mechanikách různé významy. Co je bezpečné pro vypalovačku CD, může být likvidační pro jiný typ SCSI zařízení. Nepomáhá ani to, že v jádře jsou ve skutečnosti dva různé filtry SCSI příkazů (jeden v drivers/scsi/sg.c, druhý v block/scsi_ioctl.c), které implementují různá pravidla. Všechny tyto důvody pravděpodobně přispěly k rozhodnutí účastníků setkání - odstranit filtrování.
Ten plán má jedinou malou chybku: Linus má na filtrování jiný názor:
Jinými slovy: filtrování příkazů z block/scsi_ioctl.c odstraníte jedině v jádře, které nespravuji já, nebo ho zrušíte jiným způsobem, který bude tak maskovaný, že si toho nevšimnu. Protože nejsem tak hloupý, abych si myslel, že je v pořádku nechat běžné uživatele nastavovat hesla ovladače nebo přepisovat firmware disku jen proto, že mají na zařízení právo zápisu. Berte to jako mé poslední slovo.
Takové prohlášení vypadá dost definitivně. Což však neznamená, že situaci nelze zlepšit. V současné době se prosazuje myšlenka nechat oprávněného uživatele provádět v tabulce pro filtrování příkazů změny. Distribuce by pak mohly dodávat nástroje, které rozpoznají problematická zařízení a podle toho upraví filtrovací tabulky. Celé by to mohlo být transparentně integrováno s funkcí hotplug. Jens Axboe napsal patch (původně byl autorem Peter Jones), který promění filtrovací seznam v samostatný objekt pro každé zařízení. Ten pak půjde nastavit prostřednictvím sysfs, takže každé zařízení by mohlo mít vlastní sadu výjimek.
Jak přesně by takové rozhraní pracovalo, to je třeba ještě prodiskutovat. Ale konfigurovatelné filtry pro každé zařízení zvlášť se zdají jako cesta správným směrem. Zůstává zachováno filtrování nebezpečných příkazů, ale rozhodování o pravidlech se přesunuje do uživatelského prostoru. Jakmile bude možné pravidla měnit, postarají se distributoři o to, aby byla jednotlivá zařízení dobře podporována. Nebo, pokud budou chtít, označí všechny příkazy jako povolené, a tím odstraní filtrování úplně.
Jestli Hansi Reiserovi nějaká vlastnost chybí, není to vytrvalost. V říjnu 2002 požádal o začlenění svého nového souborového systému reiser4 do vývojového jádra 2.5 předtím, než přejde do stabilizační fáze před vydáním 2.6. Uplynuly téměř čtyři roky, během kterých prošel reiser4 nekonečnými debatami v konferenci linux-kernel, mnoha změnami opravujícími nalezené problémy, odstraněním základních funkcí a dlouhým čekáním v jádře -mm. Přes to všechno stále reiser4 není v hlavním jádře - ale Hans se nevzdává.
Do této chvíle bylo nutno překonat množství překážek. Funkce "soubory jako adresáře" upravovala POSIXovou sémantiku způsobem, který některým lidem nebyl milý, a navíc způsobovala zásadní potíže se zamykáním; funkce byla odstraněna. Ne všichni pozorovatelé považují výsledky výkonnostních testů za důvěryhodné. Přetrvávají obavy z toho, jak se budou vývojáři reiser4 o souborový systém starat, jakmile bude začleněn. Hans je známý svými problémovými vztahy s ostatními vývojáři jádra a nereaguje vždy zrovna uhlazeně na (ne vždy zrovna uhlazené) komentáře kritiků. Výsledkem je trnitá cesta k začlenění souborového systému, který však skutečně nabízí zajímavé nápady a potenciálně špičkový výkon.
Částečně kvůli pocitu, že se proces začleňování reiser4 táhne už příliš dlouho, se do konference debata vrátila. Hans a spol. by rádi dosáhli zařazení reiser4 do jádra 2.6.19 a vypadá to, že by nakonec mohli uspět.
Stále je tu několik otázek, i když některé z nich možná nejsou tak problematické, jak si občas lidi myslí. Největší z nich je pravděpodobně koncept pluginů. Pluginy souborovému systému umožňují chovat se jinak ke každému uloženému souboru; je díky nim možné přidat funkce jako komprimaci nebo šifrování a další tajemné věci, které se teď dělají pomocí FUSE. Pluginy však ve vývojářské komunitě spustily hodně varovných signálů. Například Linus říká:
Dokud jim říkáte "pluginy" a chováte se k nim tak, nemám (a tuším, že spousta dalších lidí také ne) o to vůbec zájem. A abych řekl pravdu, spousta lidí si pomyslí, že hlavním účelem je buď podkopat copyrightová pravidla jádra, nebo přinejmenším vytvořit zmatek nekompatibilních sémantik bez rozumných pravidel pro zamykání atd.
Jeff Garzik si také dělá starosti:
Nechtěl bych zajišťovat technickou podporu pro distributora, za nímž přijde zákazník s padlým reiser4 v případě, kdy si zákazník tajně nahradil standardní inodovou strukturu dat interně napsaným pluginem a rovněž tajně nahradil adresářový algoritmus uzavřeným pluginem od VyberSiProdejce. Nechtěl bych se tím zmatkem probírat debuggerem.
Vývojáři chtějí, aby tvůrci reiser4 vzali na vědomí fakt, že podobný mechanismus, má-li vůbec smysl, by měl být implementován v rámci vrstvy VFS, ne v určitém souborovém systému. Reiser4 pluginy jsou vnímány jako samostatný, soukromý VFS, který může nadělat spoustu potíží.
Co si však mnoho lidí neuvědomuje, je to, že otázka pluginů je teď daleko méně problémová než bývala. Nelze je natáhnout za běhu, takže není nutné mít starost kvůli copyrightu jako u uzavřených jaderných modulů. A většina funkcí pluginů byla na základě komentářů odstraněna. Andrew Morton, který kód nedávno prohlížel, poznamenal:
Vypadá to, že jsou pluginy označovány za příliš velkého strašáka - jde jen o interní abstrakční vrstvu, která umožňuje pozdější čisté a bezpečné přidávání funkcí. Určitě nestojí za všechen ten povyk.
Podle Andrewa je největším problémem absence přímého I/O a podpory rozšířených atributů. Přímý I/O možná není příliš vzdálen, ale nevypadá to, že by mohly být v blízké budoucnosti připraveny i rozšířené atributy. To mimo jiné znamená, že by reiser4 nemohl mít podporu SELinuxu. Takové omezení by mohlo způsobit, že někteří distributoři vynechají podporu reiser4, i kdyby byla začleněna v hlavním jádře.
Zbývající stížnosti by mohly stačit k tomu, aby odradily některé uživatele či distributory od používání reiser4, ale zdá se, že nejsou dostatečné k tomu, aby zabránily zařazení do hlavní větve. Nový souborový systém se netýká těch, kteří jej nepoužívají, a problémy, které měli jeho uživatelé (například zamrzání) jsou snad už dávno pryč. Takže Hansovo dlouhé čekání se možná chýlí ke konci.
Článek o síťových kanálech z minulého týdnu naznačil, že kanály možná nejsou řešením budoucnosti. Od té doby proběhlo hodně diskuzí o tom, jak by se síťování mohlo pohnout kupředu - a kanály by mohly ještě hrát roli.
Na rozdíl od jiných operačních systémů postrádá Linux systémové volání pro obecné hlášení o událostech. Místo toho používají linuxové aplikace volání jako poll(), aby zjistily, kdy čeká nějaká práce. poll() bohužel problém neřeší úplně, takže aplikační smyčky událostí musí dělat komplikované věci, aby se vypořádaly například se signály. Zpracovávání asynchronního I/O v rámci tradiční linuxové smyčky událostí může být obzvlášť nepříjemné. Kdyby existovalo jediné rozhraní, který by aplikaci poskytlo veškeré potřebné informace o událostech, byly by aplikace mnohem jednodušší. Je to také příležitost k výraznému zvýšení výkonu.
Jsou dva návrhy linuxového rozhraní pro události: mechanismus kevent a API kanálu událostí navrhované Ulrichech Drepperem na letošním linuxovém symposiu v Ottavě. Ve výhodnější pozici je teď kevent, protože existuje funkční implementace, kterou si lze prohlédnout. Většina diskuze se tedy zaměřovala na to, jak kevent vylepšit.
Původní API kevent je považováno za trochu moc složité; závisí na jediném multiplexním systémovém volání (kevent_ctl()), což je přístup, který není všeobecně moc schvalován. Volání také vyžaduje, aby aplikace sestavila pole se dvěma různými typy struktur, a to je poněkud neohrabané. Jedním z prvních návrhů tedy bylo oddělit jednotlivé části API. Aktuální kevent patch (1. srpna) obsahuje nové systémové volání:
int kevent_get_events(int ctl_fd,
unsigned int min_nr,
unsigned int max_nr,
unsigned int timeout,
void *buf,
unsigned flags);
Toto volání by vrátilo mezi min_nr a max_nr událostmi a ukládalo by je postupně do buf, dokud by nevypršel timeout (určený v milisekundách). Parametr flags není v současné implementaci využit.
Na tomto rozhraní by šlo vylepšit hned několik věcí, ale jak se zdá, finální podoba bude pravděpodobně dost odlišná. Současné rozhraní i nadále vyžaduje častá systémová volání kvůli stahování událostí; linuxová systémová volání jsou sice rychlá, ale při velkém vytížení by stejně bylo lepší strávit pokud možno více času v uživatelském prostoru. Mohlo by to být možné při použití jiného přístupu k hlášení o událostech.
Nápad, o kterém se mluvilo, navrhoval namapování pole kevent struktur mezi jádrem a uživatelským prostorem. S takovým polem by se zacházelo jako s kruhovým bufferem a mohlo by být spravováno pomocí indexového mechanismu podobného kanálům, který by příliš nezatěžoval keš. Jádro by do bufferu ukládalo události ve chvíli, kdy se staly, a uživatelský prostor by je zpracovával. Kdykoliv by byla událost ke zpracování, aplikace by ji získala bez jakéhokoliv zásahu do jádra. Jakmile by takový mechanismus fungoval, mohlo by být volání kevent_get_events() nahrazeno prostým rozhraním "počkej na události" (ačkoliv glibc by téměř jistě nabídla synchronní funkci "získej události"). Výsledkem by bylo velmi rychlé rozhraní - zvláště při vysokém počtu událostí.
Stále je však potřeba vyřešit pár problémů. První se týká situace, kdy se buffer zaplní. Současné asynchronní I/O rozhraní neumožňuje, aby bylo více čekajících operací než je dostupných kontrolních blokových struktur; tak je zaručeno, že bude dost místa na hlášení o stavu každé operace. To může být důležité, protože ta část jádra, která chce provádět hlášení, často běží na úrovni softwarového nebo hardwarového přerušení. Pokud si však představíme použití kevents pro sledování tisíců otevřených soketů, neznámého počtu událostí týkajících se spojení atd., začne být čím dál více nepraktické alokovat všechny struktury událostí napřed. Při zaplnění bufferu se tedy bude muset provést něco chytrého.
Druhý problém se týká událostí "spuštěných úrovní" [level-triggered], které více odpovídají specifickému stavu než skutečné události, která proběhla. "Na tento soket lze zapisovat" je příkladem takové události. Když se pro zjišťování toho, jestli bude zápis blokován, používá rozhraní jako poll(), může jádro ověřit stav a okamžitě vrátit, je-li možné na daný popisovač souboru zapisovat. Hlášení takových věcí přes kruhový buffer je o dost těžší. Ať tak nebo tak, aplikace budou muset tento typ událostí zjišťovat přímo.
Vzhledem k tomu, že se jedná o exponované téma, je pravděpodobné, že se brzy objeví způsob, jak tyto potíže vyřešit. To by mohlo zamést cestu pro začlenění kevents do hlavního jádra třeba už v 2.6.20.
Utilita udev má jasně určený úkol: brát informace z jaderných událostí a virtuálního souborového systému sysfs a používat je k vytváření souborů zařízení odpovídajících skutečné konfiguraci systému. Když udev selže, je systém částečně nebo zcela nepoužitelný - situace, která se uživatelům obvykle dost nelíbí. Takže když Andrew James Wade nahlásil selhání udev při použití nedávného -mm jádra, vývojáři zpozorněli.
Ukázalo se, že problém je způsoben určitými změnami v sysfs, které mají zlepšit správu napájení. Konkrétní chybu lze opravit přidáním jiného patche, ale ten na oplátku vede k dalším potížím; několik distrucí přestává fungovat, protože verze udev, kterou dodávají, je příliš stará na to, aby rozuměla novému formátu sysfs. Andrew Morton si stěžoval, že Fedora Core 3 nefunguje, ale problém bude pravděpodobně rozšířenější.
Greg Kroah-Hartman, vývojář zodpovědný za změny, reagoval takto:
To distro už není podporované, že jo?
Jak dlouho bys chtěl, aby jádro podporovalo nepodporovaná komunitní distra, která jinak těží z faktu, že jsou rychle aktualizována? [...]
A ano, stáhnu z hlavního jádra ten patch, který lidi nutí upgradovat na udev z FC5, a počkám s ním na další verzi (minumum pak bude 081, která byla vydána v lednu 2006 - až bude venku 2.6.19, bude už 10 měsíců stará).
Andrew nebyl nadšen:
Jde mi (opět) o to, že se bavíme o zmrzačení _všech_ dister starších deseti měsíců. Nehrajeme si přeci na "ahá, ale to už nepodporujeme"... Fakt blbé. Víš, jaké všechny stroje přestanou fungovat? Já tedy ne.
Mezi distribuce, které by s vydáním 2.6.19 přestaly fungovat, patří mimo jiné i Ubuntu 6.06 LTS ("dapper") a ještě nevydaný Slackware 11. Takže není překvapivé, že se takové změny nelíbily více lidem. Je dost pravděpodobné, že bude celá sada patchů stažena a znovu promyšlena.
Greg však pokládá zásadní dotaz: Jak dlouho by se měla komunita starat o distro po té, co jej opustili jeho tvůrci? Tradiční odpověď by zněla "navždy", ale s novou generací nástrojů, které přenášejí "jádro do uživatelského prostoru", je těžké takový slib dodržet. Nástroje jako udev jsou těsně propojené se souborovým systém sysfs, který je zase téměř přímou reprezentací interních jaderných datových struktur. Sysfs svým způsobem funguje jako interní jaderné API, ale ve skutečnosti jde o rozhraní pro uživatelský prostor. Udržovat jej stabilní a vyhýbat se problémům s nekompatibilitou se staršími uživatelskými nástroji dá hodně práce. Navíc to ztěžuje skutečnost, že se vývojáři jádra pořád snaží vymyslet, jak by měl sysfs vlastně fungovat.
Na letošním jaderném summitu se mluvilo o přibalení nástrojů jako udev ke zdrojovým kódům jádra a distribuování celého balíku dohromady. Nová jádra by byla vždy doprovázena novými funkčními verzemi udev a některé z problémů s nekompatibilitou by zmizely. Není však možné takto přibalit neomezené množství nástrojů a každopádně je těžké vnímat takový přístup jako cokoliv jiného než hack pro obejití skutečného problému, který představuje udržování stability tak širokého a komplexního ABI.
Tento konkrétní problém bude pravděpodobně tak či onak zažehnán, ale určitě nebude poslední. Budou-li vývojáři jádra i nadále slibovat věčně stabilní uživatelské ABI, budou muset řešit všechny jeho aspekty - ne jen systémová volání. Nebude to snadné: moderní systémy vyžadují komplexní komunikační možnosti mezi jaderným a uživatelským prostorem. Ale vývojáři už vyřešili spoustu nelehkých problémů; s ohledem na zvýšenou pozornost, která je věnována zpětné kompatibilitě ABI, je pravděpodobné, že si poradí i s tímto.
15.8.2006 00:34
David Ježek | skóre: 83
| blog: Mostly_IMDB
)
15.8.2006 13:50
David Ježek | skóre: 83
| blog: Mostly_IMDB
Nebo Forth, tam je to občas hodně podobný. Ale Linus je systémák, že jo. I v Cčku se dá dělat data-driven programming, ale v kernelu na to člověk asi nenarazí...
Apropos životaschopnost Forthu:
http://www.intellasys.net/products/24c18/SEAforth-24B-3.pdf
24000 Forth MIPS při půlwattu spotřeby. To je celkem špatný výsledek, mají pravděpodobně poměrně starou výrobní technologii, už v roce 2001 byly dokonalejší verze, ale tohle je asi "good enough" a ekonomičtější. Nicméně pořád je to víc než dost. Tahle technologie jen tak nevymře...nejlepší implementace jsou právě ty křemíkové. Myslím, že hranici 1 TIPS/W pokoří právě nějaký forthovský čip.
Ale vážně:
Nevím o ničem, co by mělo větší poměr výkon/spotřeba a zároveň i poměr výkon/složitost než asynchronní zásobníkové MISC čipy. Navíc kopírovat design procesoru v programátorském modelu je velmi schůdné právě u zásobníků (obojí je pak jednoduché a slušně efektivní) a naprostý humus u registrů (obojí je pak buď hnusně složité nebo neefektivní a člověk si může vybrat, co z toho mu vadí míň. ). A jestlipak vy víte, že mezi kanonickým zásobníkovým počítačem (který samozřejmě má své praktické mouchy ) a PR procesorem je veliké množství výhodnějších mezistupňů?
Tvrzení, že "stack je mrvej" drze hraničí s neinformovaností. V mém mobilním telefonu se nachází procesor napůl zásobníkový, s instrukční sadou vhodnou k přímému provádění zásobníkového bajtkódu Javy. To asi znamená, že mám napůl mrtvý telefon...nebo napůl nemrtvý, mám se ho začít bát?
Že něco funguje a používá se to ve většině případů ještě neznamená, že to je pěkný design nebo že by to nešlo líp. GPR architektura má i přes svoje nedostatky nahoněný výkon spoustou ad-hoc obezliček typu zřetězení, out-of-order-execution, register renaming, instrukční cache, dložitými kompilátory a podobně. Díky tomu existuje. Tedy funguje, přestože jen jako primitivní stavový automat - ale co, na to jsou všichni zvyklí.
Jelikož si s architekturou počítačů pohrávám už nějakých těch patnáct let, něco jsem si z toho odnesl. Nemohu si pomoci, elektronika mě naučila vážit si jednoduchosti jako nejvyššího měřítka krásy. Očividně se však spousta lidí, co mají něco společného s počítači, pořád ještě nestačila povznést nad Turingův stroj.
Snad se najde aspoň někdo, kdo má křemík v lásce.
Jelikož si s architekturou počítačů pohrávám už nějakých těch patnáct let, něco jsem si z toho odnesl.Jóóó? Vždyť jeden chlapík (nevím teď kdo) na živě tvrdí, že procesorům vůbec nerozumíš?
I když, hmmm...mně ten telefon fakt nefunguje. (Ale neříkejte nikomu, že to je proto, že jsem si zapomněl u kamaráda na chatě nabíječku... )
Jo telefon musím taky upgradovat, 13-letý synovec mi ten starý pohanil. Cituji: ,,Černobílá shitka, takovej nemají ani ty nejhorší dyliny ze třídy''. Vypadá to na K510i.
> Jelikož si s architekturou počítačů pohrávám už nějakých těch patnáct let, něco jsem si z toho odnesl. Nemohu si pomoci, elektronika mě naučila vážit si jednoduchosti jako nejvyššího měřítka krásy.
Jednoduchost je subjektivní, mě se zase líbí 68K, MIPS a PowerPC. Uveďte prosím libovolný zásobníkový CPU, který je výkonově srovnatelný s běžnými register-based RISCy (tj dělá aspoň 1000-2000 MIPS/Watt).
„1) zásobníkově orientované instrukce jsou sice jednoduché, ale je jich pro stejný algoritmus potřeba cca 2x více, než u register-based architektury (viz třeba ten paper co jsem postoval link).“To je možné, ale: - dnešní implementace těch instrukcí v zásobníkových procesorech jsou téměř vždy pětibitové (šest instrukcí na každý 32bitový fetch!), takže kód je pořád kompaktní a většinou i kompaktnější kvůli výhodám, zmíněným dále. - zvýšený throughput to vykompenzuje nebo i naprosto přebije, kvůli výhodám, zmíněným dále.
„2) pokud většina instrukcí implicitně hýbe se stackem, nejde to jednoduše superscalovat (ani hlouběji pipelinovat), protože dekodér dopředu netuší kam bude stack ukazovat, a tedy odkud má načítat argumenty. Tohle u registrů nevadí, store-load konflikty u stejného registru jednoduše překladač proloží něčím jiným.“Tohle je ale irelevantní. Zásobníkové procesory nemají pipeline. V každém taktu provedou jednu instrukci a tím to pro ně hasne. Dekodér naopak naprosto přesně ví, kde zásobník bude – vrchol zásobníku je na vrcholu zásobníku, druhý prvek je těsně pod ním a tak dále. Odpadá tedy latence z dekódování adresy a připojení správného registru k ALU, čímž se sníží hloubka hradlové sítě, kterou se propagují změny signálů v každém cyklu, a tedy se i zvýší taktovací frekvence. (V každé hradlové síti je žádoucí při maximalizaci výkonu omezovat počet průchodů hradly v řadě za sebou v každém taktu, ne?
) Zákonitě ani nedochází k žádným konfliktům, data dependency v jednom toku instrukcí je absolutní a je to součást designu. IMHO jen malá oběť za procesor s patnácti tisíci tranzistory a několika gigahertzy taktu při pár miliwattech spotřeby, protože člověk jich pak může mít, kolik chce.
Absence zřetězení také znamená absenci branch penalties, což umožňuje volání podprogramu v 1 cyklu (nebo i v 0 cyklech u některých bizarnějších architektur) a návrat z podprogramu v 0 cyklech (typicky bitovým příznakem) témeř zadarmo, bez složité logiky pro branch prediction a tedy s dalšími úsporami příkonu a počtu tranzistorů při současném zachování výkonu, což je při pipeliningu nemožné. (V konečném důsledku to potlačuje i potřebu instrukční cache, protože kompilátor může sám umístit hotspoty do rychlé místní paměti a skákat do nich bez ohledu na ztráty výkonu z větvení – žádné nejsou – kdežto RISC model, pipelining a inlining vedou k bobtnání kódu a potřebě velké instrukční cache s asociativní pamětí adres - hromada křemíku, spotřeby a peněz.)
Žádnou z těchhle výhod zásobníkové operace na běžném pipelinovaném registrovém stroji pochopitelně nemají, ale právě proto se pro zásobníkové výpočty navrhují procesory „poněkud“ vhodnější.
„Jednoduchost je subjektivní, mě se zase líbí 68K, MIPS a PowerPC. Uveďte prosím libovolný zásobníkový CPU, který je výkonově srovnatelný s běžnými register-based RISCy (tj dělá aspoň 1000-2000 MIPS/Watt).“Uvádím to všude: Pět let staré jádro c18 má při výrobě relativně starou 180nm technologií 120000 MIPS/Watt. Je to osmnáctibitové, tak si to vynásobte třeba 0.6, a protože to je zásobníkové, klidně ještě vydělte dvema nebo třemi, pro mě za mě...
Ale mám dobrou zprávu: Ohledně 68K a MIPSu se shodneme. (Proč bych jinak sbíral Silicony a DECy... )
Vývoj musel opravdu udělat ohromný skok, protože slova "moderní zásobníkový CPU" jsem naposled slyšel koncem 80ých let v souvislosti s firmou INMOS, a i tam byl zásobník jen z nouze- potřebovali rychlé kontextové switche tak museli zahodit registry.
decode-load-execute-store v jednom taktu bez pipeliningu? Jakou magii ty procáky používají, aby to při takhle extrémně dlouhých kritických cestách běhalo na gigahertzech?Jakákoli dostatečně pokročilá technologie je nerozlišitelná od magie...
Bohužel nemám přístup k firemním tajemstvím, jen k faktům o existujících designech. Já netuším, můžu se jen dohadovat. Případně se člověk může ponořit do patentových spisů. (Nějaké konkrétní patenty části designu pokrývají.) Vím jen, že se ještě dají objednat od autorů prototypy procesoru f21, který pracuje na šestkrát vyšší frekvenci, než výrobní továrna říká, že dotyčná technologie vůbec umožňuje (500 MHz místo ~70-80 MHz - pamatujete všemi milovaný čip 486 DX/2? ). Nějaké info a snímeček je třeba v téhle PowerJointové prezentaci. (Mimochodem, byl navržen pomocí softwaru o velikosti 10 KB. )
Tuším ale, že součástí té magie bude plně asynchronní logika jádra, geniální mozek návrháře a ruční tweaking a informovaná rozhodnutí na základě přesných simulací, která si člověk může dovolit při počtu tranzistorů ~10000, ale ne při počtu tranzistorů o tři řády vyšším. Přesto se Intel snaží některé z těch technologií využít také. (Vždyť ani Speedstep nepochází z jejich dílny, nemohli si ho patentovat, jelikož to už někdo udělal před nimi. )
Navíc honit gigahertzy je u úsporných CPU obecně blbej nápad, protože pokud ekvivalentní gate load potřebujete nabít za poloviční čas, potřebujete dvojnásobný proud, tedy čtyřnásobný výkon. Proto je lepší zvyšovat spíš IPC než takt, a v tom jsou RISCy docela dobré.Tyhle procesory se neznaží maximalizovat ani takt, ani IPC, ale througput dat na počet tranzistorů (jestli to tak můžu vyjádřit) nebo na spotřebu...
Věřím, že to je v konečném důsledku asi ta nejpodstatnější věc.
co má společného RISC model a inlining?Možná jsem to nevyjádřil přesně.
Pipelining je nepřátelský vůči větvení, dokonce i s branch prediction, což je docela známý fakt. Kompilátory proto často provádějí inlining jako techniku, která má kód urychlit. Dále jim to znemožňuje separovat časté sekvence instrukcí do kódu, do kterého se bude skákat, což je naopak u stack machines právě technika, se kterou se počítá a která má dále redukovat velikost kódu (a omezit nebo eliminovat potřebu I-cache, jak jsem už psal).
Google "c18 core" mi dalo pár linků, ale 1) nikde se 120GIPS/W neuvádí 2) není to jen nějaký obskurní Harward s onchip ROM a pár kilobyte SRAM?Harwardský design to jádro, pokud vím, nemá. Přinejmenším některé jeho implementace umožňují spouštět kód přístupný i jako data. Je pravda, že je primárně určeno pro resource-contrained aplikace. Sám autor přeci tvrdí: "Optimized for compute-bound portable applications." Nemyslím si ovšem, že tohle nějak omezuje použitelnost v jiných aplikacích. Třeba při roztažení šířky slova na 32 bitů, přidání větší on-die paměti a paměťového řadiče a externích rozhraní pro vnější paměť a periférie se poměr výkon/spotřeba asi nijak drasticky nezmění, statická paměť pravděpodobně nemá nijak zvlášť vysokou spotřebu oproti multigigahertzovému procesorovému jádru navrženému tak, aby se v něm žádný hradlo neflákalo.
To, co říkáte, se týká zásobníkových procesorů první generace... Ty se opravdu moc neujaly, ale u nich vývoj neustrnul. Srovnávat dnešní zásobníkové čipy s Burroughsem B5000 by bylo asi stejně smysluplné jako srovnávat Pentium s Univacem – tedy hloupé. U softwaru naopak zásobníkový model jaho úhelný kámen toku dat při provádění kódu vznikl později než registrový, poněvadž IBM/360, pokud je mi známo, žádný zásobníkový assembler neměla (a na počátku by ani nebyl použitelný kvůli špatnému mapování na tehdejší procesory - viz níže). Je tedy hloupost tvrdit, že „zůstal“.
A pokud jde o výkon registrových strojů...to máte těžký, emulovat jedno na druhém. Obojí vyžaduje složitý kód: Java musí běžet typicky na registrových strojích (s výjmkou mého telefonu... ) a proto musí používat JIT kompilátor s alokátorem registrů – interpret byl moc pomalý, historie ho odsoudila. Registrový bajtkód překládaný do kódu zásobníkového procesoru také není to pravé ořechové, zásobník má tu vlastnost, že hotspot je navrchu, a přerovnávat registrové instrukce do zásobníku s minimalizací stack jugglingu asi taky nebude sranda.
Nicméně vyšší jazyky (o které dnes jde především) se snáze překládají do zásobníkového kódu než do registrového, dobře navržený zásobníkový procesor je velice výkonný a hlavně je mnohem jednodušší (z čehož plyne podstatně vyšší pro) a poměr výkon/spotřeba může mít až stonásobný. To jsou fakta. Průmysl je ovšem supertanker, jakkoliv rychlé jsou pokroky v některých oborech výpočetní techniky, Von Neumann a Turing tu jsou stále s námi a nesmíšený model zásobníku s oddělenými daty a návratovými hodnotami céčkomilům prostě nesednul, i přes očividné výhody, a bez něj nic z tohohle nejde.
Měl bych takové pěkné video, a jak říkám, asi je to téma na blogpost se spoustu úderných argumentů. (Třeba ten, že nemožně zastaralým technologickým procesem 486ky jde vyrobit 500 MHz zásobníkový procesor, který bude mít dvacetinový počet tranzistorů a mizivou spotřebu, je docela pěkný. )
Mimochodem, pár stovek řádků kódu má kompletní CAD systém, pomocí kterého pan Moore své procesory navrhuje. Alokátor registrů o velikosti CADu, to je zajímavá myšlenka.
Jednodušší než co? RISCy jsou podle vás složité? PIC nebo AVR máte taky do 20k hradel.Jedna reference viz výše (nebudu ji už opakovat): F21, 500 MHz při 800nm procesu, 100 mW (je to stará výrobní technologie
) - CPU, videoprocesor pro barevný videovýstup, hodně slušně programovatelná jednotka anologového vstupu/výstupu a docela komplexní jednotka pro síťovou komunikaci. To vše v 15000 tranzistorech, ne hradlech. Ale bohužel se jednalo o "solution without problem", takže se v té době (~1998) nenašla vhodná aplikace. Škoda, pár bych jich zaměstnal...
Co je jednodušší, zkompilovat zásobníkový mezikód pro registr s N registry nebo zrekompilovat registrový mezikód pro M registrů pro procesor s N registry?Lze obojí, ale první je jednodušší. Pro JIT kompilaci je zásobníkový pseudokód vhodnější, je blíž zdrojáku, ale ještě lepší je použít přímo syntax tree. Pro exekuci (ať už interpretem nebo v křemíku) je lepší registrový kód. Horší hustota kódu je víc než vyvážena lepším výkonem.
CPU, videoprocesor pro barevný videovýstup, hodně slušně programovatelná jednotka anologového vstupu/výstupu a docela komplexní jednotka pro síťovou komunikaci. To vše v 15000 tranzistorech, ne hradlech. Ale bohužel se jednalo o "solution without problem", takže se v té době (~1998) nenašla vhodná aplikace. Škoda, pár bych jich zaměstnal...Nojo, jasná konspirace. Některé z těch 13 familií co jak všichni víme vládnou světu se to asi znelíbilo. Radši to nebudu moc řešit, nebo mě zas rozbolí hlava z hrubejch vibrací. PS: Přečetl jsem si toto interview s Chuckem Moore, a vypadá na pěkného omezence. To že má někdy pravdu na tom moc nemění. Zvláštní, doposud jsem na zavilé forth-isty nenarazil, netušil jsem že je ta víra tak tuhá.
Nojo, jasná konspirace. Některé z těch 13 familií co jak všichni víme vládnou světu se to asi znelíbilo. Radši to nebudu moc řešit, nebo mě zas rozbolí hlava z hrubejch vibrací.Srandičky, srandičky, srandičky.
A co VHS a Windows? No jo, unixové systémy mají postavení, jaké si právem zaslouží. Ať žije úspěšný Microsoft! Ne, vážně. O iluzi, že postavení na trhu je úměrné přímým technickým kvalitám, jsem přišel už pred mnoha lety. Ovšem ti, co mají extrémní nároky, nejsou hloupí. Původní téma diskuze nebylo "co je nejlepší", ale "stack je mrtvý?"...a já se pouze snažím vyvrátit to druhé, poněvadž to vidím kolem sebe v celkem hojné míře. (A to nejen jako člověk s téměř dvaceti lety zájmu o kosmonautiku a astronomii, kde tyhle technologie nalezly slušné místečko. )
PS: Přečetl jsem si toto interview s Chuckem Moore, a vypadá na pěkného omezence. To že má někdy pravdu na tom moc nemění. Zvláštní, doposud jsem na zavilé forth-isty nenarazil, netušil jsem že je ta víra tak tuhá.Víra? V jeho případě spíš bohotvorství, ne?
Ten člověk téměř před padesáti lety Forth vymyslel jako nástroj pro sebe a zatím nenalezl lepší prostředek pro své potřeby, on nemusí věřit. Proto má být omezenec? Jsou Linus Torvalds, Larry Wall, Matz a Kvído von Rozum "zavilí a omezenci"? Já nevím, já si vážím každého z těchto lidí a pana Moorea také, za to, co díky nim máme. (Mnohem víc, než velkých hamižných firem...)
A kromě toho, géniům bývá leccos odpuštěno. Já mu odpouštím jeho výstřelky, ostatně tak v tuto chvíli mohu učinit díky jeho technologiím (mám v notebooku úsporný procesor od Intelu ). Ostatně Richarda Stallmana taky skousnu.
15.8.2006 09:54
rudiik | skóre: 16
| blog: rudiikuv miniblog
15.8.2006 20:34
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
Nezbývá mi nic jiného, než reagovat a současného modelu se zastat. Uživatelé mají příliš velké požadavky na podporovaný sortiment HW a výrobci HW se činní v tom, aby množství různých, často obskurních, zařízení s časem exponenciálně rostlo. Rešení je buď prohlásit, že stabilní řada 2.6 bude osahovat podporu pro hardware kompatabilní/vyrobený např. před rokem 2005 (což by způsobilo více křiku než současný model) nebo všechno backportovat a forwardportovat mezi stabilní a vývojovou větví. Forwardportování a snaha podporovat silně se rozcházející větve povede k vzniku ošklivého kódu. Backportování je zase strašné urpení a práce, když se pěkný kód musí mrzačit aby chodil s již zastarávajícími základy subsystémů. Další možnost je zpomalit vývoj základu (kdo by však nechtěl robust-mutex, PI atd) nebo získat mnohem více vývojářů.
Nový model tedy podle mého názoru šetří síly. Širokým testováním zajišťuje, že se ve vývojové větvi nenaakumuluje hromada skrytých chyb a umožňuje distribucím dodávat jádra s určitým odstupem od čela vývoje, která jsou již rozumě stabilizovaná a přitom podporují většinu nového hardware. Přitom rozdíl ve verzích je natolik malý, že ještě lze minimálně bezpečnostní opravy a opravy driverů bez větších problémů backportovat. Bohužel některé vylomeniny v API a věcech jako je UDEV pak uživatelům občas přinesou perné chvilky.
Menší komunity, jako třeba ARM Linux, již opravdu sílami na dvoukolejnou schizofrenii nedisponují.
Pokud distributoři poskytují svoje změny zpět do mainline jádra, tak se nemusí velkých potíží bát. Ti co si vymýšlejí polouzavřené vývojové větve postavené na hromadě úprav a proprietátních konfiguračních utilit, které nedohodnou a nepřipraví pro začlenění do mainline, a prohlašují, že jejich jádro je lepší než všechna ostatní, tak zatáhnou uživatele do slepé větve. Pak jim vše přeroste přes hlavu.
Podívejte se na množství chudáků bojujících s komerčními distribucemi pro ARM a jiné embedded systémy založenými na jádře 2.4.18 či 2.4.20. Výsledek je katastrofa. Řada 2.6.x naopak chodí spolehlivě. S minimem patchů si s ní hraji na mašem HW od verze 2.6.8 a lokální patchstack se mi s časem zmenšuje, protože jediné místo, kde lze rozumně patche spravovat je mainline strom.
Je ovšem pravda, že začlenení kódu je proces často extrémě nákladný na trpělivost a schopnost komunikovat. V žádném případě Hansovi nezávidím. Na druhou stranu většinou proces eliminuje zmetky.
Podla mailinglistu Slack by nefungoval lebo má udev 071, ale -current má už pár dní 097 (a 96 tam bola o trochu dlhšie). Takže Slack fungovať bude. (odhliadnuc od toho, že udev vôbec nemusíte použiť)
Jinak udev je dobra myslenka (a to rikam pri plnem vedomi toho, ze vim, kdo je jeho autor ), ale opravdu by melo byt vice distribuovano primo s jadrem, v podstate se jedna o funkci jadra umistenou v userspace. A protoze Linux o stabilnim ABI nic nevi a je stale ve vyvoji, nevidim pri nazorech GKH jinou alternativu.
ale opravdu by melo byt vice distribuovano primo s jadremSouhlas. IMHO cokoli co vyžaduje jádro by mělo být dodáváno s ním, ve zdrojovém kódu.
15.8.2006 20:38
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
).
Koncep UDEVu plně chápu a pro desktopy má význam. Bohužel je trošku nepříjemné, když se vám po hodinách portování, pokusů a omylů podaří spustit jádro na právě navržené desce s řádkou init=/bin/sh a zjistíte, že se bez hromady skriptů a nebo překynutého statického /dev nedostanete na readonly filesystemu ani k sériáku, který má zrovna major:minor 204:41. No nic situace se lepší, nějaká podpora je již alespoň v BusyBoxu a všechna zařízení snad již reportují major:minor přes /sys.
Když se ovšem podívám na následující vrchol programátorské hamby (např. v linux/drivers/usb/core/usb.c usb_find_interface()) který se od verze v 2.6.11 v LXR změnil do dnešního 2.6.18-rc4 pouze o přidání dalšího overheadu v lockování, tak mě to nadšení z UDEVu přechází. Přitom každý subsystém si to musí řešit zvlášť a většinou to končí na staticky předalokovaných polích minorů. Přitom pod DevFS to chodilo s jednou referencí přes ukazatel. Chápu, že jsou s ní potíže s lockováním a cyklickými referencecounty, ale slušný návrh takové věci, jako je O(N) hledání, neobsahuje. Na doporučení, že to mám reportovat jinde, dopředu uvádím, že jsem si na to KHG stěžoval již v okamžiku, kdy se prohlásil za pána nad /dev a vítězoslavně obdržel souhlas s postupným zlikvidováním DevFS, které již předtím zbavil všeho, co ho dělalo zajímavým. Statických tabulek indexovaných minory se tedy ve svých driverech nezbavím
PS: neví někdo, jestli je někde LXR pro aktuální jádra?
A kdyz se to podarilo, tak se usetrila cesta z Brna do Prahy. To neni spatna odmena.
16.8.2006 11:23
michich | skóre: 51
| blog: ohrivane_parky
16.8.2006 16:24
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
). Udev ovšem právě tuto nejistotu nadobro odstraňuje, stačí si napsat příslušné pravidlo a daný kus HW bude na věky věků vždy identifikován stejně
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
15.8.2006 08:22