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í
×
dnes 01:11 | Nová verze

Wayfire, kompozitní správce oken inspirovaný Compizem běžící nad Waylandem, byl vydán ve verzi 0.5.0. Zdrojové kódy jsou k dispozici na GitHubu. Videoukázky na YouTube.

Ladislav Hagara | Komentářů: 0
včera 12:22 | Komunita

Neziskové technologické konsorcium Linux Foundation rozšířilo seznam svých oficiálních projektů. Nejnovějším projektem je Open Source Security Foundation (OpenSSF), jehož cílem je zvýšit bezpečnost open source softwaru. Více například v příspěvcích na blozích GitHubu nebo Microsoftu.

Ladislav Hagara | Komentářů: 0
včera 11:44 | Nová verze

Byla vydána verze 3.1 webového aplikačního frameworku napsaného v Pythonu Django (Wikipedie). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 01:11 | Nová verze

Svobodná federalizovaná sociální síť Mastodon byla aktualizována. Vydání 3.2 mj. přepracovává audio přehrávač, zlepšuje zabezpečení přihlášení aj.

Fluttershy, yay! | Komentářů: 0
3.8. 14:00 | Komunita

Byla vydána verze 1.5.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace. Na YouTube jsou ke zhlédnutí záznamy přednášek z konference JuliaCon 2020 konané online minulý týden.

Ladislav Hagara | Komentářů: 0
3.8. 13:33 | IT novinky

Sdružení CZ.NIC informuje, že pro domény s koncovkou .CZ, jejichž platnost nebyla včas prodloužena, platí opět ochranná lhůta 60 dnů (30 dnů je doména plně funkční, 30 dnů je vyřazena z DNS – není dostupná). Po více než čtyřech měsících tak končí zvláštní režim, kdy byla funkčnost nezaplacených domén dočasně prodloužena ze 30 na 60 dnů z důvodu mimořádné situace související s onemocněním COVID-19.

Ladislav Hagara | Komentářů: 23
3.8. 09:00 | Nová verze

Byla vydána nová verze linuxové distribuce BunsenLabs Linux s předkonfigurovaným správcem oken Openbox. Její název je Lithium a založena je na Debianu 10 Buster. Přehled novinek v poznámkách k vydání. BunsenLabs Linux je nástupcem dnes již nevyvíjené linuxové distribuce CrunchBang (zkráceně #!).

Ladislav Hagara | Komentářů: 0
3.8. 08:00 | Nová verze

Po 9 týdnech vývoje od vydání Linuxu 5.7 oznámil Linus Torvalds vydání Linuxu 5.8 (LKML). Přehled nových vlastností a vylepšení na stránce Linux Kernel Newbies.

Ladislav Hagara | Komentářů: 1
3.8. 07:00 | Komunita

Omar Roth, hlavní vývojář Invidious, alternativního webového frontendu k YouTube, oznámil, že kvůli přehlcení a nedostatku motivace projekt opouští a zřejmě skončí také oficiální instance invidio.us (k 1. září, resp. API k 1. říjnu); stále poběží další instance nebo je možné nasadit vlastní.

Fluttershy, yay! | Komentářů: 0
2.8. 14:22 | Zajímavý projekt

Byly vyhlášeny výsledky soutěže JS1024 2020 aneb zajímavé programy napsané v JavaScriptu o velikosti maximálně 1 024 bajtů. Více o vítězném pianu na stránkách autora.

Ladislav Hagara | Komentářů: 0
Dokážete si představit, že by váš hlavní počítač (desktop, notebook) byl v současné době založen na architektuře jiné než x86 (x86_64)? Například ARM, POWER, RISC-V,…
 (10%)
 (10%)
 (57%)
 (16%)
 (7%)
Celkem 129 hlasů
 Komentářů: 11, poslední dnes 08:59
Rozcestník

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

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

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.