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
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(_BitScanForward). Funkce samozřejmě nefungují v C++ constexpr režimu.
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?
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
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
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)
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++?
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.