Jaderné noviny – 2. 8. 2012: Jak se kompilátorům brání v optimalizacích (diskuse)

[Let_Me_Be]

Achjo, tyhle volatile prasarny fakt stoji za to. To makro ma fungovat presne obracene. Volatile ma byt default a pokud z nejake promenne nepotrebuju cist z vice vlaken tak si ji poznacim jako ne-volatile.

[dumblob]

+1

[Michal2]

Já jsem člověk, který ten kód musí psát, takže by mě SRALO kdybych v 99.99 (spíše ještě více) % pripadu musel předepisovat nonvolatile. Tudíž ti dávám -1

[D.A.Tiger]

+1

[Michal Vyskočil]

A vy běžně v kódu běžně píšete třeba takové auto?

[Sten]

auto označuje automatický typ, ne automatickou dedukci kompilátoru za pomoci binární křišťálové koule, jestli něco má být volatile nebo ne.

[Michal Vyskočil]

S tím souhlasím, ale jak to souvisí s tématem vlákna?

[Sten]

To, že nonvolatile by se muselo předepisovat i u všech prototypů funkcí a definicí struktur.

[Michal Vyskočil]

No ono by hypotetické --std=little.owl bylo asi dost nekompatibilní s jakýmkoli jiným C, takže asi ne :)

[little.owl]

ono by hypotetické --std=little.owl bylo asi dost nekompatibilní s jakýmkoli jiným C

Ja se rad pobavim na svuj ucet, ale tady mi nejak nedochazi. Proc --std=little.owl ?

[Michal Vyskočil]

No už jenom změna typu proměnné na volatile a zavedení nového klíčového nonvolatile slova je přeci na nový standard A jiné jméno, než --std=little.owl mě prostě nenapadlo. Nic ve zlém.

[little.owl]

Spojovat muj nick s takovou, od zacatku, peachovinou me temer urazi!

[Let_Me_Be]

Jasne. 99.99% promennych sdilenych mezi vlakny nepotrebuji byt volatile. To je fakt dobry blabol.

[tom]

* Zjevne jste nepochopil, jak to Michal2 myslel.

* Promenne chranene mutexy/semafory/syscallem opravdu volatile byt nepotrebuji a takovych promennych je v userspace programech vetsina.

[Let_Me_Be]

Ale na ty snad tohle makro (o kterem se tady bavime) pouzivat nebudu, ne?

[R]

Bud by si mal vsade volatile, alebo by bol vykon vies kde...

[Let_Me_Be]

Ano protoze je mnohem lepsi mit v pripade chyby podivne chovani kodu a nahodne hodnoty v promennych nez mit v pripade chyby nizsi vykon :-/

[Sten]

Takže kód by vlastně vůbec neměl používat registry? (To je totiž význam volatile) Měl by taky za každou operací, která modifikuje paměť, provést memory barrier, aby se změna skutečně projevila na všech jádrech, protože jinak na to bude potřeba nějaká „další prasárna“? Tipuji, že jste nikdy nic takhle nízkoúrovňově nedělal, proto nemáte tušení, jak pomalá by taková aplikace byla.

[Let_Me_Be]

Mam pocit ze neumis cist. Protoze to co pises se absolutne nevztahuje k tomu co jsem napsal ja. Cely vyznam toho makra je totiz v tom ze se volatile nepouziva a jenom tam kde je to potreba se pouzije tohle makro. Coz je prasarna.

[Sten]

To ale může způsobovat výkonostní problémy v zamčených místech, kde je vhodné, aby se zámek držel co nejkratší dobu.

[Let_Me_Be]

No a prave proto by to makro melo fungovat obracene. Kdyz mas vykonnostni problem (coz je vec, ktera se hleda mnohem lepe, nez vznik nahodne hodnoty) tak si tu promennou poznacis jako ne-volatile.

[Kvakor]

Normální SMTP procesory memory barrier nepotřebují, mají speciální obvody, co zajíšťují koherenci cache a paměti mezi jádry (tj. tu "prasárnu" dělá hardware ). Memory barrier je třeba až když se přistupuje k MMIO, ale jen pokud procesor neumí vypnou cachování jinak, např. u x86 jsou na to MTRR a u x86_64 atributy stránek.

[pc2005]

Normální SMTP procesory

SMP nebo link! :-O

[Kvakor]

Jasně že tam mělo být SMP, tohle byla jen IT varianta freudovského přeřeknutí

[pc2005]

A já se tak těšil na novou architekturu .

[Sten]

Já se teda na SMTP procesory netěším. Toho spamu je už teď hodně

[little.owl]

Svet je pestrejsi a na jinych platformach to neplati, tohle jsou implementacne a platforme zavisle veci.

[deda.jabko]

To mi prijde jako nesmysl, mnozstvi sdilenych promennych by melo byt co nejmensi, aby v tom byl poradek. S tvou logikou by se dalo tvrdit, ze vsechny promenne by mely byt z podstaty globalni a kdyz ji chci lokalni, tak si ji tak mam deklarovat.

[Let_Me_Be]

Co ma pocet sdilenych promennych spolecneho s tim ze ty ktere jsou sdilene maji byt volatile?

[deda.jabko]

ze ve slusnem kodu mas male mnozstvi sdilenych promennych (nejlepe) na jednom miste a mas je oznacene jako volatile a ostatni promenne to nepotrebuji, ergo implicitni volatile je nesmysl.

[Let_Me_Be]

Ale o nesdilenych promennych se tady vubec nevime. Bavime se tady o tomhle makru, ktere umoznuje mit sdilene promenne implicitne ne-volatile.

[pc2005]

Všechny proměnný ne, ale všechny proměnný definující zámky ano. Zajímalo by mě kolik se na tom ACCESS_ONCE ušetří času.

P.S. Nejvtipnější pak je, když se přetypovává proměnná, která už volatile je . Např. tady.

[little.owl]

Tam nejde o usporu casu, ale o to, ze promenna muze byt asynnchronne zmenena z jineho threadu a tudiz nektere predpoklady na zaklade nichz kompilator muze udelal optimalizaci proste neplati.

[Ivan]

JJ, tohle jsou ty nejnechutnejsi chyby. Takovy system muze bezet mesice a vsechno krasne funguje. A najednou se pri vetsi zatezi vyhrouti s nejakou obskurdni chybou. Lidi co umi tohle fixnout jsou fakt machri, vetsinou se ale takova chyba vyresi az kompletnim prepsanim kusu aplikace.

[pc2005]

Jo a buď by měly být všechny takový proměnný, kde může zapisovat 2 a více vláken, definovaný jako volatile (pak je ACCESS_ONCE zbytečné a je to workaround špatně definovaného kódu) a nebo se ptám jak velký výkon získám variantou: nesdílené proměnné + zamykatelné proměnné + proměnná, kterou mám nadefinovanou jako neměnnou, ale občas ji použiju jako volatile.

(když se nějaká proměnná jmenuje "lock" tak bych čekal, že bude už jako volatilní definovaná a nebudu ji muset přetypovávat)

Taky by mě zajímalo zda je nějaké využití efektu, kde musí být proměnná v jednu chvíli aktuálně načtená a po zbytek programu už může zůstat v registru.

[little.owl]

Jo a buď by měly být všechny takový proměnný, kde může zapisovat 2 a více vláken, definovaný jako volatile

Ani volatile vam moc nepomuze,to je jen hint pro kompilator aby to nezoptimalizoval, volatile nevklada memory barrier.

[pc2005]

Ovšem ACCESS_ONCE je volatile taky, nebo nějak paměťovou bariéru řeší? Jinak je to offtopic.

Samozřejmě v případě potřeby paměťové bariéry by se tam nějaká hodila.

[little.owl]

ACCESS_ONCE je volatile a to resi jen to ze vam kompilator neudela nejake nepredlozenosti pri optimalizaci. To zdali to budete moci bezpecne pouzit z vice vlaken, bude zalezet na implementaci kompilatoru a kontextu v jakem je kod pouzit - jedno jadro, pres stejne cache a podobne, cele je to implementacne zavisle.

[pc2005]

Mě jde o to, proč a zda je výhodnější přetypovat proměnnou někde v kódu a ne rovnou v definici.

[little.owl]

Protoze to nemusi nestacit. Vy muzete napriklad k promenne pristupovat neprimo pres pointer jako k mistu v pameti a tam snadno kompilator dostanete do uzkych. Navic tohle reseni vam umozni toto chovani lokalizovat tam kde je to potreba.

[little.owl]

Ehm: Protoze to nemusi stacit.

[pc2005]

Aha, tedy vzhledem k tomu, že lze udělat volatile pointer i pointer na volatile i volatile pointer na volatile proměnnou a za předpokladu, že tohle kompilátor ustojí. Pokud ne, tak je dost slabej (což ale klidně může být).

Tedy některé programy používaj pointery, které občas ukazují na volatile proměnnou a občas na normální? To mě přijde ale dost hazardní.

[Sinuhet]

Ted byste mel jeste vysvetlit, jak vam pomuze, ze pri pristupovani k promenne z vice vlaken si ji oznacite jako volatile.

[pc2005]

[rejp] Kromě speciálních případů nebude potřeba používat žádné makro [/rejp]

[Anonymous]

Náhodné generátory čísel, nebo generátory náhodných čísel?

P.S.: Děti věděly.

[Luboš Doležel (Doli)]

Díky.

[Sten]

Náhodné generátory náhodných čísel

[Marek]

…Concurrency není věcí vestavěnou přímo do jazyka C…

od dubna 2011 a C verze C11 to už umí. Je otázka jak to umějí kompilátory a jak se s tím popasují při kompilaci kernelu.

[little.owl]

Vzhledem k tomu, ze kernel se nedostal plne ani k C99, je mluveni o C11 v tomto kontextu z rise snu.

[JoHnY2]

Souhlas. Na druhou stranu, nikdo nerika, ze jadro musi pouzivat zrovna uplne vsechno z C99 nebo C11. Pokud se dobre ohlidaj konflikty, tak neni problem pouzivat casti C11 relativne brzo.

[zulu]

Já bych teda od "access once" čekal právě to, že první for se má chovat jako ten druhý.

[pc2005]

Jo mě to taky mate: Access once = načti jednou a pak recykluj hodnotu.