Vlákno názorů k článku Vulkan: představení a první jednoduchá aplikace od rrrado1 - Nič proti výnimkám, ale rýchlejšie to nemá byť...

Nič proti výnimkám, ale rýchlejšie to nemá byť prečo, tie podmienky sú len skryté v tom hpp wrapperi.

naopak ac vyjimky kod zprehledni, rozhodne ho nezrychli

U vyjímek je jen jedna podmínka úplně naspod, jestli operace selhala a má se házet. Odpadnou všechny další podmínky v callstacku, které ten chybový stav propagují nahoru.

Nehovorím o kóde,ktorý používa tento vulcan wrapper, ale z poľadu výkonu, podmienky sa len skryli do medzivrstvy, ten wrapper je plný takýchto podmienok:

if ( result != VULKAN_HPP_NA­MESPACE::Resul­t::eSuccess )
{
throwResultEx­ception( result, "vkCreateAcce­lerationStruc­tureKHR" );
}

Je to v poriadku, len si nemyslím, že vďaka tomu je výsledný kód rýchlejší, ako to je uvedené v článku.

Ale ono jde práve o ten kód, co ten wrapper používá. Ten wrapper sám o sobě tu chybu nemá jak ošetřit. Takže je na výběr ji propagovat ven výjimkou nebo skrz nějaké chybové kódy. A u těch chybových kódů bude na každé (nebo skoro každé) vrstvě test.

Jde o to porovnávat jabka s jabkama. Má smysl dívat se na celou cestu chyby od místa vzniku až do místa, kde se ošetří. A to už výjimky můžou (ale taky nemusí) být výrazně rychlejší. Optimalizovat jednu vrstvu odděleně má smysl jen pokud ty optimalizace do ostatních vrstev nezasáhnou. A to u propagace chyb rozhodně neplatí.

Přesně!

Pokud uděláme pět úrovní zanoření, pak bez výjimek testujeme pro kód chyby na všech pěti úrovních. Vždy se ptáme zda nám zavolaná funkce vrátila success nebo nějakou chybu. Pokud použijeme výjimky, tak porovnání zůstává pouze na nejvyšší úrovni zanoření, kde otestujeme, co nám vrátilo cizí API (třeba Vulkan) a podle toho vyhodíme výjimku nebo ne. Z této funkce už pak už nemusíme vracet chybový kód a nadřazená funkce už nemusí nic testovat. Test tedy zůstal jen na páté úrovni zanoření a ze zbylých čtyřech byl eliminován. Dá se tedy předpokládat, že méně instrukcí porovnání a skoků způsobí rychlejší běh kódu. Toto mi potvrdil i jednoduchý experiment na g++ a s MSVC. V kódu, který velmi intenzivně volal funkce a vracel chyby, přineslo použití výjimek i dvojnásobné zrychlení. Budete-li mít jinou zkušenost, sem s ní.

Vynimky su nahodou velmi uzitocne. Tazsie sa potom pise spagetak a ulahci to pracu ludom ktori to musia opravovat. Funkcia ktora tu vynimku vyhodi spracovava len svoju ulohu, a funkcia ktora tu vynimku odchyti a spracuje riesi zase svoju ulohu...

Teda ak nejakeho blazna nenapadne ze pouzije vynimky pre riadenie behu programu, aj to uz som videl na vlastne oci...

Výjimky slouží k řízení běhu programu v případě chyby :)

To jsi ještě neviděl veci... a lidé mi pak vyčítají že jsem sprostý když to pak rozmotavaji lidi celý rok a já přicházím o volný čas.

Když ti devel co vylezl z univerzity napíše takove "kreativni" exkrementy a je pak ještě ve vedení projektu je téměř nemožné ho vykydlit.

Nemůžeš ho pak prevelet ani do energy divize protože by chudáček nepřežil code review.

3. 7. 2021, 19:18 editováno autorem komentáře

S těma špagetama je to těžké. Výjimky jsou dvojsečná zbraň. Výjimečné stavy programu jsou taky stavy programu. Akorát jsou díky své vzácnosti nejmíň promyšlené a otestované.
A výjimky k tomu jako bonus přidají to, že zrovna ty problematické cesty v kódu nejsou při čtení zdrojáku vůbec vidět. Psát kód tak, aby jeho invarianty přežily když uprostřed vyletí nějaká neočekávaná výjimka, není vůbec jednoduché.

Podla mna dvojica try..catch velmi presne vymedzuje problematicky usek.

Ak niekde vyleti neosetrena vynimka pocas ostrej prevadzky, tak to poukazuje na odflaknute testy.

Tak ten try...catch je na té úrovni, kde se ta výjimka chytá. Na nižších úrovních, skrz které ta výjimka cestuje nahoru, nemusí být patrné vůbec nic.