abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 10:55 | IT novinky

Josef Průša představil novou 3D tiskárnu Original Prusa MINI. Její cena je 9 990 Kč a tisknout lze na ní objekty do velikosti 18 × 18 × 18 cm.

Ladislav Hagara | Komentářů: 28
12.10. 13:11 | Nová verze

Byla vydána nová stabilní verze 3.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu. Projekt lze podpořit na Patreonu. Aktuálně má přislíbeno 5 697 dolarů měsíčně.

Ladislav Hagara | Komentářů: 1
12.10. 12:22 | Komunita

Larry Wall odsouhlasil přejmenování programovacího jazyka Perl 6 (Wikipedie) na Raku. Více viz Issue #81 a Pull request #89.

Ladislav Hagara | Komentářů: 8
11.10. 23:33 | Nová verze

Byla vydána nová major verze 2.0 open source systému pro filtrování nevyžádané pošty Rspamd (GitHub, ChangeLog). S novou verzí bylo změněno označování verzí z major.minor.patch na major.minor.

Ladislav Hagara | Komentářů: 0
11.10. 14:11 | Zajímavý článek

Fakultu informatiky Masarykovy univerzity navštívili v rámci Týdne s držiteli Turingovy ceny profesoři Donald Ervin Knuth a Dana Stewart Scott. Zveřejněn byl videozáznam z úterních Otázek a odpovědi s Donaldem Knuthem: Umění programování.

Ladislav Hagara | Komentářů: 6
11.10. 05:55 | Nová verze

Siteshwar Vashisht oznámil vydání KornShellu (Wikipedie) ve verzi 2020. Jedná se o novou stabilní verzi vydanou po více než šesti letech. Zdrojové kódy a changelog jsou k dispozici na GitHubu. Siteshwar Vashisht přednášel letos o KornShellu na konferencích FOSDEM 2019 a All Systems Go! 2019.

Ladislav Hagara | Komentářů: 1
11.10. 04:44 | Komunita

Na zítra – 12. října – připadá letošní Mezinárodní den proti DRM (Wikipedie). DRM je zkratkou pro Digital Rights Management nebo Digital Restrictions Management.

Ladislav Hagara | Komentářů: 12
10.10. 08:33 | Zajímavý software

Google na svém blogu věnovaném open source představil a na GitHubu zveřejnil zdrojové kódy nástroje SchedViz pro vizualizaci plánovaní procesů (scheduling) v Linuxu.

Ladislav Hagara | Komentářů: 0
10.10. 05:55 | Nová verze

Byla vydána nová verze 1.39 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.39 bylo vydáno také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

Ladislav Hagara | Komentářů: 21
9.10. 22:44 | Nová verze

Byla vydána nová stabilní verze 19.09 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Loris. Přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.

Ladislav Hagara | Komentářů: 0
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (19%)
 (4%)
 (11%)
 (39%)
 (24%)
 (2%)
Celkem 386 hlasů
 Komentářů: 22, poslední 23.9. 08:36
Rozcestník

www.AutoDoc.Cz

Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?

26. 6. 2016 | Redakce | Jaderné noviny | 43286×

Stav vydání jádra. Leemhuis hledá regrese. Čas na atomicitu z C11?

Stav vydání jádra

Současný vývojový kernel nese označení 4.7-rc3, vydán byl 12. června. Linus k tomu řekl: „Přehled změn vypadá docela normálně a neškodně. Tentokrát mají souborové systémy větší podíl než obvykle, ale vesměs se jedná o nově přidané testy btrfs, které když ignorujete, zbývají celkem obvyklé věci: dominují ovladače (grafické a síťové představují většinu, a pak i i2c, rdma,…) spolu s aktualizacemi architektury a nějakým tím obecným kódem pro sítě. A konečně nahodile ode všeho trochu jako vždycky.“

Thorsten Leemhuis se prozatím chopil dlouho zanedbávaného úkolu hledání regresí v -rc jádrech. Zatím se mu v 4.7-rc3 povedlo najít 21 regresí.

Stabilní aktualizace: Žádné nebyly tento týden vydány.

Čas na atomicitu z C11?

Klasický program napsaný v C vypadá jako deterministický seznam kroků v jistém pořadí. Na co už ale programátor nevidí, to jsou změny pořadí operací, které může za účelem urychlení běhu programu provést překladač nebo CPU. Jestliže pracujeme pouze s jedním vláknem, je přeřazování operací, aniž by došlo k poškození programu, relativně jednoduchá záležitost. Neplatí to však v případě, kdy se stejnou pamětí pracuje najednou více vláken. V případě více vláken jsou vývojáři často nuceni explicitně vznést požadavky na uspořádání.

Za tímto účelem jádro definuje celou řadu paměťových bariér a atomických operací, jejichž cílem je zachování pořadí přístupu do paměti (memory access ordering) v místech, kde je to důležité, při zachování výkonu. Standard C11 jazyka C se snaží vyřešit stejný problém jinou sadou bariérových operací. Opět je na místě ona otázka: Měl by kernel dát přednost operacím definovaným standardem C před svými vlastními operacemi?

Tato otázka se naposledy objevila v roce 2014, viz shrnutí na LWN o tom, jak atomické operace C11 fungují a jak se může při nedostatečně kontrolované změně pořadí operací pokazit souběžný přístup k paměti. Podpora atomických operací ze standardu C11 se mezitím v překladačích zlepšila a David Howell přišel s plnou implementací atomických operací jádra (pro x86), postavenou právě na C11. Implementace samotná je vcelku přímočará, například funkce atomic_read() vypadá takto:

static __always_inline int __atomic_read(const atomic_t *v, int memorder)
{
    return __atomic_load_n(&v->counter, memorder);
}
#define atomic_read(v)		(__atomic_read((v), __ATOMIC_RELAXED))
#define atomic_read_acquire(v)	(__atomic_read((v), __ATOMIC_ACQUIRE))

Davidovy patche ukazují, že konverzi provést jde. Otázkou zůstává, zda by se měla udělat. Jak by se dalo očekávat, existují argumenty pro i proti.

Přechod k atomickým operacím z C11 by teoreticky měl umožnit vyhození spousty složitého, na architektuře závislého kódu pro bariéry z jádra – místo toho by se využilo stejného kódu, leč zabudovaného přímo do překladače, který budou souběžné programy uživatelského prostoru využívat. Atomicita z C11 poskytuje překladači lepší přehled o tom, co kód doopravdy dělá, otevírá více příležitostí k optimalizaci a použití instrukcí, které je těžké vyvolat v inline assembleru. Překladač také může vybrat instrukci, která odpovídá velikosti operandu, čímž dokáže eliminovat přerostlé větvení vyhodnocované při překladu ve stávajících hlavičkových souborech jádra.

Současné překladače zdaleka nevyužívají všechny možnosti optimalizace, ale potenciálně by ty budoucí mohly překonat ručně psaný, vyladěný kód v assembleru. Jak k tomu řekl Paul McKenney:

Souhlasím, že pro C11 může být těžké porazit precizně optimalizovaný kód v assembleru. Ale nemusí to trvat až zas tak dlouho, než překladače porazí jednodušší ručně psaný kód v assembleru. Nakonec, překladače můžou časem překonat i ten optimalizovaný kód v assembleru ve složitějších případech jako cykly cmpxchg.

Další výhodou je schopnost překladače přesunout konkrétní bariéry pryč od atomických operací samotných, pokud se tím dosáhne vyššího výkonu. Takové přesuny u inline assembleru nejsou možné.

Přechod ale samozřejmě přináší také nevýhody. Jednou z nich je, že atomicita z C11 je pořádně implementována pouze v nejnovějších překladačích. David říká, že generovanému kódu bude k optimalitě hodně scházet před vydáním gcc-7.1, a to je vydání, na které si počkáme ještě skoro rok. Přesně podle očekávání se objevuje spousta chyb, která s atomicitou z C11 souvisí. Jsou sice hlášeny a opravovány, ale pravděpodobně jich ještě přibude. Z dlouhodobého hlediska by používání atomicity z C11 jistě vedlo k zavedení robustnějšího překladače, ale cesta nejspíš bude trnitá.

Když se jádro sestavené pro běh na víceprocesorovém systému (to jsou téměř všechna) dostane na systém jednoprocesorový, odstraní nepotřebné synchronizační instrukce z vlastního kódu. Při použití atomicity z C11 nebude něco takového možné, nelze totiž zjistit, kde se tyto informace nacházejí, a sebemenší změny v překladači mohou vést k nevídaným zmatkům. Jednoprocesorové systémy jsou čím dál tím vzácnější a jednorázově sestavená jádra jsou pro ně vesměs k dispozici, ale stejně by bylo lepší takové systémy zbytečně nezpomalovat.

Konečně, asi největší potenciální problém spočívá v tom, že model paměti implementovaný pomocí atomicity z C11 do jisté míry neodpovídá modelu, který používá jádro. Model C11 je postaven na sémantice acquire/release – tedy na jednosměrných bariérách, o kterých byla řeč ve výše odkázaném článku z roku 2014 a v tomto článku. Velká část jádra místo toho používá load/store bariéry, které jsou jednak přísnější, jednak obousměrné. Zápis do paměti s release sémantikou bude dokončen pouze v případě, že jsou veškeré předchozí operace čtení nebo zápisu viditelné v celém systému, ale umožní přeřadit jiné operace, provedené logicky po zápisu, tak, aby byly vykonány před příslušným zápisem. Zápis se sémantikou store místo toho striktně řadí ostatní operace zápisu na obou stranách bariéry.

Jednou možností by bylo zeslabit paměťový model jádra tak, aby architektura, která využívá sémantiky acquire/release, mohla dosáhnout na příslušné výkonnostní benefity. Je však jasné, že taková změna by mohla přinést náchylnost k těžko odhalitelným chybám. Proto je k tomu nutné přistupovat opatrně. David poznamenává, že PowerPC již zřejmě se zeslabeným modelem pracuje, takže přímo v jádru už nutně nemusí číhat tolik problémů.

Jak podotkl Will Deacon, atomicita z C11 postrádá, krom jiného, dobrou implementaci operací consume load, které tvoří důležitou součást mj. RCU. Consume load může být vždy nahrazeno operací acquire, leč za cenu horšího výkonu. Will se obává, že model C11 není vhodný pro architekturu ARM a že výsledkem záměny může být nepraktická kombinace C11 a operací specifických pro jádro. Souhlasil však s tím, že generická implementace založená na C11 by byla užitečným nástrojem pro vývojáře, kteří portují jádro na novou architekturu.

Zatím o nápadu proběhla o poznání kratší diskuze než minule. Možná, že se vývojáři pomalu smiřují s myšlenkou, že ke změně nakonec stejně dojde, i když se to nyní zdá předčasné. Výhody by taková změna přinesla jak pro jádro, tak pro komunity kolem překladačů. Zatím se nepovedlo rozseknout, zda tyto výhody převažují nad nevýhodami.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

27.6.2016 00:08 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Tak jestli není pořádně nahraditelná atomicita v RCU, tak bych to snad ani nenahrazoval, to by se klidně mohlo celé rozsypat ([joke] ... a z linuxu vzniknout jednotaskovej OS :-D [/joke]).

Možná by bylo jednodušší to změnit v GCC.

P.S. Ví někdo jaká je nejstarší verze GCC, kterou jde zkompilovat jádro? Já začal až na 3.xx, ale řekl bych, že za tu dobu se to klidně mohlo posunout.
27.6.2016 08:24 vgy
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
GCC mi bezne nedokazalo skompilovat programy, co jeste pred nejakejma verzemi gcc skompilovat slo. Oproti tomu Microsoft kompilator to iste napric verzema dokazal skompilovat. GCC je pro mne smejd. Aby clovek neustale opravoval program kvuli tomu, ze je gcc vylepsene.
27.6.2016 09:24 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Ve svém svatém rozhořčení jste zapomněl zmínit jeden důležitý "detail": jestli ten zdroják byl opravdu korektní podle normy jazyka nebo jestli překladač jen začal odmítat něco, co korektní nebylo, ale dříve to toleroval.
27.6.2016 21:01 Ccfjdj
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Na to staci vypnut -pedantic -Werror.
27.6.2016 22:52 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Nestačí. S každou verzí přibývají optimalizace, kdy se program i přeloží, ale kvůli konstrukcím s nedefinovaným chováním se výsledná binárka chová jinak. Pak naopak zapnutá varování jsou důležitá. Každopádně stěžovateli bych doporučil program opravit, nebo neaktualizovat překladač (nebo alespoň přes -std zamknout verzi C).
28.6.2016 07:00 Homer Simpson
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
(Homer Simpson šéfem směťáků):
A nemohl by to udělat někdo jinej?
(počítač na velikým projektu?) A poté firma skrachovala a město se přestěhovalo... do Redmontu
28.6.2016 09:02 fe
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Tak Visual Studio je hoooodně benevolentní a „skousne“ některá přetypování, které GCC ale hlavně Clang nezkousne a nahlásí jako error.

Je čistě filozofická otázka co je správně – já se přikláním na stranu GCC a Clang, které vynucují standardy jazyka.

Ale z mé praxe v multiplatformním vývoji, ti co kompilují na GCC/Clang stále dokola opravují kód vyprodukovaný těmi, co programují ve VS. A podle toho co za poslední roky vidím, MS by měl svůj kompilátor opravdu zlepšit a standardy dodržovat.
2.7.2016 12:43 Petr Ježek | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Potvrzuji tuto zkušenost. Problém programátorů z Redmondu byl a je, že standardy definoval management a vlastníci, nikoli kybersystém a jeho tvůrci. Bohužel jde o široce rozšířený nešvar, který je v poslední době pouze lépe vidět poté, co se v MS tváří přívětivě na multiplatformálnost.
Archlinux for your comps, faster running guaranted!
little.owl avatar 4.7.2016 12:03 little.owl | skóre: 22 | Brighton/Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Pak se jedna o hodne prasacke programy stavejici sve chovani na nespecifikovanem nebo implementacne zavislem chovani. A pokud nekdo pise user space programy tak, ze je to "bezne", je lepsi ho poslat past ovce.
$ man rtfm
27.6.2016 09:21 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Minulý týden jsem zrovna narazil na thread, kde tahle otázka padla. Podle dokumentace je potřeba aspoň 3.2, ale nikdo si netroufá dát ruku do ohně, že jádro touhle verzí opravdu přeložit jde. A nikomu se pochopitelně nechce instalovat gcc 3.2 a zkoušet to, natož pak dělat nějaké důkladné testy, jestli aktuální jádro přeložené gcc 3.2 funguje správně.
27.6.2016 09:54 koroptev
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Zdrojaky jadra nejsou korektni podle normy? Nebo gcc pred 3.2 nebylo schopne kompilovat korektni veci a pote ano?
27.6.2016 10:17 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Nejsou. Pokud by vás to náhodou opravdu zajímalo, nebude pro vás problém zjistit si proč. Pokud jako obvykle jen trollujete, nestojí za to ztrácet čas vysvětlováním.
27.6.2016 10:21 ced
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Ano. zrojáky jádra nejsou místy korektní podle normy. Sice nejsem autor jádra a nemluvím o celém jádře, ale to co jsem četl, nebylo striktně podle normy. Bylo to podle dokumentace GCC. Včetně těch sekcí jako GCC only nebo experimental. Upřímně, ono ani podle normy napsat ne vždy jde, ale někdy jsem měl dojem, že když si autor dal práci se čtením experimentálních novinek v GCC, rozhodl si to procvičit na jádru, bez ohledu na to, že u nich bylo napsáno, že nikdo nezaručuje stejné chování i do budoucna.

little.owl avatar 4.7.2016 12:05 little.owl | skóre: 22 | Brighton/Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Kernel je jedna z veci, ktera nutne zavisi na nespecifikovanem a implementacne zavislem chovani, zavisejice jen na C standardu to napsat nelze.
$ man rtfm
28.6.2016 17:42 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
GCC 3.2 vyšlo 2002, tak to by mohlo trvat dalších 14 let než na ty funkce přejdou :-D. Nejhorší bude stav, kdy pojede půlka architektur na starým mechanismu a půlka na novým.
2.7.2016 12:46 Petr Ježek | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Při použitelné a současně i používané existenci clangu jde o nesmyslný argument. Clang je dobrou příležitostí zmíněné diskrepance eliminovat.
Archlinux for your comps, faster running guaranted!
2.7.2016 14:29 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?
Clang už zkompiluje kernel? Každopádně bude řešit stejný problém jako gcc a to je implementace vestavěných atomických operací vs implementace v kernelu. Nezapomeň, že v kernelu musí být různé varianty pro různé architektury (některé ani neumí SMP) a pak jsou lidi, co třeba laděj zámky (článek tady v jaderných novinkách před nějakou dobou).

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.