Aligned structures a Windows

[Vilem Otte]

Tento post je především myšlen pro další potenciální "oběti" dobrého "vtipu" MS Windows.

Představte si velmi jednoduchou třídu standardního float4:

[Crypton]

Tohle rozhodně nebude chyba na straně MS Windows, či MSVC. Za prvé ti tam chybí explicitně nastavené zarovnání u deklarace té třídy (__declspec(align(16)) popř. __attribute__ ((aligned (16))) ), takže instance alokované na zásobníku budou špatně zarovnané, a za druhé, alokace takových tříd se standardně provádí přes přetížený operator new (tj. přímo v té třídě), kde si můžeš tu paměť alokovat pomocí standardního globálního operatoru new, a zarovnat si tam tu paměť podle sebe (takže to bude přenosné).

A za třetí, to zarovnání u té proměnné xmm sice bude 16 bytů, ale relativně k adrese paměti alokované pro instanci té třídy float4.

Taky záleží jaké operace nad těmi daty provádíš, a jaké instrukce k tomu použiješ, některé totiž vyžadují zarovnání 16 bytů, a některé zase ne (movaps vs. movups).

Není pak divu že ti to hází segfaulty..
_________________

[Vilem Otte]

[Crypton]

Ano, ten typ __m128 je zarovnaný na 16 bytů, ale když ho máš jako proměnnou ve třídě, tak to zarovnání té proměnné v paměti je relativní k začátku té alokované paměti pro tu instanci té třídy, takže pokud ti alokátor vyplivne kus paměti který je zarovnaný jen na 8 bytů, tak ta proměnná xmm nebude zarovnaná na 16 bytech.

V tom příkladě alokuješ nezarovnaný blok paměti (který je i tak malý, protože ti tam chybí rezerva na zarovnání toho ukazatele), který pak přetypuješ na instanci té třídy, takže proto ti to padá.

_________________

[Vilem Otte]

[Al]

Toto je zajímavé téma a rád bych k němu něco napsal, ale v podstatě se 100% shoduju s tím, co psal Crypton, takže jen Crypton: palec nahoru.

Mít ve svém programu chybu a křičet "Windows toto a Windows tamto"... hm, klasika. A testovat to dokonce na různých verzích Windows, jaký to má jako mít smysl? Paměť pro objekty přece alokuje C Runtime Library na své haldě, to nedělá přímo operační systém. Nebo se pletu? Jasně, tazatel vůbec nenapsal, jakou verzi překladače C/C++ používá, což je asi úplně nejzásadnější věc v tomto problému. Teoreticky může být implementace celé haldy přes funkce operačního systému, protože Windows haldy umí přímo systémově, ale to by přece zbytečně zpomalovalo program, ne?

Doporučuji se na to zeptat na stackoverflow, tam jsou lidi, co tyhle zdánlivé "chyby" vždycky rychle vyvrátí citací nějaké části ze standardu jazyka ISO C++, kde je přesně popsáno to zdánlivě špatné chování jako správné.

[TeaTime]

Tohle se tedy projevuje jen na Windows? Moc jsem nepochopil to co jsi tam psal o Debianu. A nevíš, jak je na tom Solaris?

[Vilem Otte]

[Al]

TeaTime: Prosím přečti si, co jsem psal. Stručně řečeno: Ta věc nesouvisí s Windows.

A přesně, jak psal Crypton, to chování je v pořádku dle specifikace programovacího jazyka. Zeptal jsem se na to pana Google a ten mi řekl přesně to, co zde psal Crypton: Prvky struktur jsuo zarovnány vzhledem k začátku struktury. Situaci můžete řešit přetížením operátoru new.

[Al]

Vilem Otte: Nechci tady vést akademické debaty o tom, co je nebo není součástí překladače. Podle mě sysétmové knihovny (C a C++ runtime library, standard template library, c0 nebo případně i další věci) jsou přece součástí toho překladače. Aspoň moje VC++ a GCC/G++ vždycky tyhle knihovny má a já je používám. Jak říkám, může to být i samostatně nebo třeba i mnou definované, ale přece neřešme akademické debaty, bavíme se o běžné situaci a jestil něco způsobuje "alokátor", když tomu tak chceš říkat, je to podle mě věcí toho překladače. Nemyslel jsem "překladač=CL.EXE", myslel jsem to ve smyslu "překladač=MSVC se vším všudy".

[Vilem Otte]

V tom případě beru zpět co jsem psal , sám jako překladač beru pouze samotný program překladače (tedy přímo programy gcc, icc, etc... či jak píšeš cl.exe).

Samozřejmě v případě že uvažujeme o "překladač=MSVC se vším kolem", tak potom je to věcí překladače.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[pcmaster]

Ja som na toto podivuhodne a uprimne smutne a zbytocne spravanie MSVC++ tiez narazil pri pisani diplomky a zdielam Vilemov smutok. Vtedy som sa len nasral a vygooglil riesenie.

Je velmi dobre, ze si to sem napisal. Prosim ta, v zaujme vsetkych co este sem chodia, ser na provokatorov a postuj dalej podobne zavazne veci, cesko-slovenska C++ i 3D API komunita bude aj nadalej vdacna.
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Tringi]

Tak či onak bych se nikdy neodvážil spoléhat na kompilér, že dostanu dynamickou alokaci více zarovnanou než na 8 bajtů (x86) resp. 16 bajtů (x86-64). Jak ze zkušeností, tak i protože trochu tuším jak jsou real-world kompilátory stavěné.

Redux následujícího je: Vilém musí zarovnávat sám, není to chyba MS, maximálně otázka QOI, protože __m128 ani __attribute__ není definováno žádným standardem C ani C++ takže se může dít prakticky cokoliv, a abychom věděli co, musíme si nastudovat příslušnou dokumentaci.

Podrobněji:

1) Umisťování zarovnávaných proměnných do struktur se bát nemusíte, nejvyšší zarovnání se propaguje do agregujícího typu, ISO C++ kapitola [3.11]. Tzn. je-li __m128 zarovnané na 16 bajtů, bude takto zarovnaná i jakákoliv struktura, která jej ponese, a před danou proměnnou se vloží dostatek padding bajtů aby se zarovnání dodrželo.

2) V tomto ohledu nemůžeme říct že by alokátor nebyl součástí kompilátoru, i když to tak reálně není nikde. Standardy C i C++ (viz dále) nařizují výchozímu alokátoru nějaké parametry, a pokud kompilátor vybere takový, který těmto neodpovídá, je to chyba kompilátoru.

3) ISO C99 pro funkci malloc specifikuje pouze, že vrácený pointer má být zarovnaný tak, aby mohl být platně přetypován na libovolný objekt. Přesněji to standard nespecifikuje. Za předpokladu, že je tím "objekt" myšlena libovolná struktura složená z fundamentálních typů, pak __m128 není ve standardu a ergo toto pro něj neplatí (bez zvláštní benevolence kompilátoru/alokátoru).

4) Současný C++ standard (C++11) v [3.7.4.1.2] specifikuje, že pointer vrácený new má mít zarovnání vyhovující typu v parametru. Má-li tento alignas(16), pak vrácený pointer musí být takto zarovnaný, a není-li, jde o defekt kompilátoru.

5) Nicméně C++98, o které zde zřejmě jde, alignas ani nic podobného nemá a tak nemůže nařizovat nakolik má standardní new respektovat nestandardní __attribute__((aligned(16)), to je otázkou implementace, která by to měla zdokumentovat. Na x86, kde nezarovnaný přístup způsobí přinejhorším prodloužení času přístupu do paměti, by všechno mohlo být zarovnané na 1 bajt a stále by to byla korektní standardní implementace, proto typických 8 bajtů berme jako velkorysost, de facto samozřejmou, ale stále velkorysost.
Jak píšu výše, korektní zarovnání dynamicky alokované paměti by významně zvedlo kvalitu implementace, opak ale není prohřešek proti standardu C++98 protože ten nic takového nespecifikuje. Ale můžu se mýlit, nemám finální dokument po ruce, tak vycházím z preliminárek a google.

6) V typické implementaci (C++98 na 32-bit Windows) new volá malloc, malloc je v msvcrt a volá HeapAlloc, pro které MS nikdy nikde zarovnání nespecifikoval. Yikes. Empiricky a neoficiálně z blogů developerů se zarovnání, na které se dá spolehnout, zjistit dají, a že by se budoucnu změnily (dolů) se čekat nedá, rozbilo by to asi pěknou řádku programů.

Dvě citace standardu C++11 pro Ala:

ISO C++ 3.7.4.1 : 2
[...] The pointer returned shall be suitably aligned so that it can be converted to a pointer of any complete object type with a fundamental alignment requirement (3.11) and then used to access the object or array in the storage allocated [...]

ISO C++ 3.11.2
A fundamental alignment is represented by an alignment less than or equal to the greatest alignment supported by the implementation in all contexts, which is equal to alignof(std::max_align_t) (18.2). The alignment required for a type might be different when it is used as the type of a complete object and when it is used as the type of a subobject.

Pro další referenci diskuze na stackoverflow:
http://stackoverflow.com/questions/506518/is-there-any-guarantee-of-alignment-of-address-return-by-cs-new-operation

Bug GCC 15795: Resolved WONTFIX:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
(hádám že kvůli C++11 se to dříve nebo později změní)
_________________
WWW | GitHub | TW

[tom.drin]

Taky trochu experimentuju s SSE a narazil jsem na obdobný problém.
Používám POSIX vlákna a gcc (mingw32) a problém je, že stack pro vlákno není zarovnaný na 16 bytů (tak jako je zarovnaný stack pro main). Poté kdykoliv použiju SSE datový typ tak to padne.
Nevíte někdo co s tím, lze nějak zarovnat vlákna?

[Tringi]

To je zvláštní ...jaké verze GCC a mingwrt používáš?
Vzpomínám si na extra okomentovaný kód na několika místech mingwrt, kde se právě kvůli SSE stack zarovnával.
Tak či onak zkus svému typu přidat zmíněné __attribute__((aligned (16))) a uvidíš.
_________________
WWW | GitHub | TW