Portál AbcLinuxu, 29. dubna 2024 07:04
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ě
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
15.8.2006 08:22