Názory k článku Funkce vestavěné v GCC pro nalezení délky sekvence nulových bitů

A já bych doplnil, že tyhle builtiny (a pár dalších souvisejících) se do C23 dostaly v stdbit.h: https://en.cppreference.com/w/c/header/stdbit.html

Díky za doplnění!

Pro doplnění aby se nezapomnělo na nás Windowsáky, Visual Studio (Microsoft Visual C++ compiler) podporuje tyto built-ins/intrinsics: _BitScanForward, _BitScanReverse od verze 2005 na všech architekturách, dále pak _BitScanForward64, _BitScanReverse64 od verze 2005 na 64bit architekturách (AMD64, IA64, ARM64). Je potřeba includovat <intrin.h> a použít #pragma intrinsics(_Bit­ScanForward). Funkce samozřejmě nefungují v C++ constexpr režimu.

Díky za doplnění. MSVC popravdě nepoužívám už X let, ale je dobré vědět, že se pořád vyvíjí.

jak casto se delaji tyto nizkourovnove operace? My je potrebujeme (pres assembler), ale to je mozna specificke - male MCU (i osmibity se porad instaluji). Na "velkych" x86 to asi neni tak moc ne?

V nějakých specializovanějších datových strukturách se to používá v C:

lib/dns/qp.c:        uint32_t log2 = 32U - stdc_leading_zeros(size - 1U);
lib/dns/qp_p.h:        return (dns_qpweight_t)stdc_count_zeros(bitmap);
lib/dns/rpz.c:                        bit += stdc_leading_zeros(delta);
lib/isc/histo.c:        int clz = stdc_leading_zeros(chunked);

predpokladam, ze v nicu delate dns a sitove servery v c. dneska je vetsinou na projektech c++. c++ ma strasne moc ruznych bejkaren a vychytavek a c mi pripada, ze zas nevymysli blbosti navic, ale zas je toho treba vice napsat.
ja bych adi chtel delat v cistem c i kdyz musim delat v c++, go, pythonu.
jak to mate s tim c?

Přiznám se, že přesně netuším na co se ptáte, ale v CZ.NICu už nejsem 8 let (cca bez pár dní).

to nebylo o nicu, ale o c vs c++.

ja jsem nucen delat v c++ 98 az 14, ale mam radsi c a go.

takze dotaz znovu, proc c jo i dneska, treba reknete i nejaky jiny duvod, nez ktery bych rekl ja sam a proto me to zajima. abych si to obhajil pred samym sebou jeste vice.

Pro hash a krypto funkce jsou potřeba rotace. Když jsou struktury v big endianu, jsou užitečné BSWAPy. Tohle naštěstí ještě umí překladač dobře zoptimalizovat, i když se to rozepíše na shift/or/and, vypadne z toho jedna očekávaná instrukce.
Na zbytek je intrinsika.

Delka sekvence bitu je zakladni kamen mnoha kompresnich algoritmu.
Takze ano.. v kodecich to vidim porad :)

Řekl bych, že novější GCC a Clang umí detekovat, že napsaný kód dělá to k čemu je dobrá nějaká instrukce a automaticky to nahradí...

- občas... záleží jak je kód napsaný

- ale je to verze od verze lepší.

to mozna jo, ale proc psat (vnitrne dost hnusnou) funkci nebo makro na neco, co uz existuje, je otestovane, zdokumentovane a plne funkcni?

Nemáš pravdu. Můžeš napsat násobení matic 4x4 jako matematický vzorec, nebo jako speciální buildin nad simd instrukcemi.

Je dost možné že překladač nakonec celou tvou transformační pipeline optimalizuje přes simd instrukce na míru tomu výpočtu zatímco při použití buildinu dojde k roztrhnutí optimalizací protože dodržení api dané funkce je nutné. Ale kdo ví doporučuju testovat

u toho SIMD myslíš spíš intrinsic než builtin funkce?

no chtělo by to otestovat, ale IMHO v takové maličkosti ještě dokážu překladač minimálně dohnat, ale spíš i předehnat :-)

buildin funkce jsou zároveň intrinsic, protože jinak by neměly smysl - prostě by se volaly callem.

A nemůžete mít buildin pro každou SIMD instrukci

Navíc, pokud skládáte matematický výpočet, tak často nemůžete dohlédnout na všechny optimalizace které by tam šly udělat

Příklad:
násobení 3 matic 4x4
https://godbolt.org/z/6jfYTz74G

(V příkladu je nějaká implementace matic, netuším jestli správně, ale aspoň to tak vypadá).
Při max optimalizaci je to doslova "několik instrukcí". Zkuste si tohle naprogramovat ručně. A co když budu chtít překládat pro ARM, SIMD buildin mi budou k ničemu, nebo se budou emulovat - ne tak efektivně

Navíc pokud "překladač vidí" do vlastního výpočtu, může optimalizovat dál. Násobení konstantní maticí je hned jednodušší kód. To jsou optimalizace, které člověka hned nenapadnou

https://godbolt.org/z/MxWf59eTE

Je třeba říct, že ne vždy. Například násobení translační matice je v clangu výrazně delší, přestože je to defacto sečtení m12,m13,m14 po složkách mezi sebou. Překladač tohle nedokázal odhalit v rámci své statické analýzy

https://godbolt.org/z/oebcj83Yh

Hlavně se zaměřte na pravý panel, kde je vidět, jak překladač poznal, co kód dělá a vybral správnou instrukci

https://godbolt.org/z/a9f9Y8b3T

Tohle je podle mne správný způsob překladu. Budoucnost bude taková, že v jazyce napíšu "co chci aby to dělalo" a překladač to poskládá i třeba jinak, když bude výsledek stejný a navíc rychlý. Dávno je pryč doba, kdy se programovalo na instrukční level

- jen si pořád nemyslím, že tím jazykem bude angličtina (AI prompt, kdyby nedošlo)

Ještě lepší příklad s ror n a rol n

https://godbolt.org/z/G8EsooYWP

jeste se zeptam i tebe jako mistra v c++, pro c++ proti c?

argumentace, ze ma c++ kratsi kod uz snad ani neplati. vyssi mira abstrakce jo, ale mi uz to metaprogramovani pripada nekdy uz zu viel

rust beru jako lepsi/horsi c++ a totez plati o golangu a c, ja mam od srdce radsi c a go.

takze to je spis pocitovka, proc c++?

Je to vyšší míra abstrakce a možnost si tu abstrakci i zadefinovat právě šablonama. V Růstu jsem absolutně bez šance

Ten instrukcni kod s prefixem REP, ktery je to tomto kontextu nesmyslny, je velmi zajimava vychytavka. Presne ve stylu Intelu. Ovsem ucel sveti prostredky. Jinak by tato instukce mela aspon 4 bytes, ne dva.
Instrukcni kody i8080 jsem znal zpameti. Z80 vetsinu. Pochybuji ovsem, ze kdokoliv na svete zna zpameti aspon vsechny instrukce dnesnich Intelu. Znat i jejich kody pak uz neni v lidskych silach.

Vsadim se, ze neznate ani vsechny registry zpameti :D
Tim myslim vsechny vsechny .. nejenom SIMD, ale taky MSR :)