Diskuze: Proč používat omezený int, když máme neomezený BigInteger
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 12 zpráv z 12.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Nedělitelnost. Jde o to že int je 32bitu tedy 4-bytovy. 32 nebo 64bit OS tak provedou rychlí výpočet bez dalších operací. BigInt je kolos a pro práci sním se musí alokovat paměťový prostor a výpočet už není přímočarý. Zabere více času procesoru a prostoru v paměti.
Co je atomicita?
Tady to znamená, že když v jednom vláknu provádíš třeba sčítání dvou intů a v druhém ten, kam ukládáš výsledek, čteš, nikdy se ti nestane, že bys viděl třeba půlku bitů sečtenou a půlku ještě ne. Ta operaci prostě nelze rozdělit na posloupnost menších operací, které by mohl někdo pozorovat.
Tyhle atomické operace se provádí jednou instrukcí, u BigIntu a jemu podobných nic takového neexistuje – dva BigInty se sčítání postupně, takže opravdu můžeš vidět půlku bitů sečtenou a půlku ještě ne.
A to je ten rozdíl ve výkonu tak strašně zásadní, že se int/long používá i když se neomezený prostor hodí, nebo má int ještě nějakou výhodu?
No za A ano rozdíl je docela velký a za B, a to je důležitější, jak často potřebuješ v běžné aplikaci číslo větší než 2,147,483,647?
>A Jak moc velký?
>B Myslím že třeba kalkulačka nebo jakákoli početní aplikace - kdybych
byl uživatel, docela by mě mrzelo kdybych nemohl počítat s velkými
čísly
Že dvakrát pomalejší je hodně?! Kdybych programoval běžně náročnou aplikaci, byla by mi úplně jedno i ta 50x větší náročnost - nedokážu si představit že by se něco takového v běžně náročné aplikaci dalo rozpoznat
A to je ten rozdíl ve výkonu tak strašně zásadní, že se int/long používá i když se neomezený prostor hodí, nebo má int ještě nějakou výhodu?
Zjednodušeně řečeno, bigint je při operaci rozdělen na menší jednotky, pro které již existují instrukce (např. sčítání velkého intu lze řešit jako posloupnost sčítání jeho částí + nějaká ta režie, podobně třeba násobení). U normálního intu (i long long int na 64bitových platformách) se prostě použije jedna instrukce a je hotovo.
Že dvakrát pomalejší je hodně?! Kdybych programoval běžně náročnou aplikaci, byla by mi úplně jedno i ta 50x větší náročnost - nedokážu si představit že by se něco takového v běžně náročné aplikaci dalo rozpoznat
To záleží, co ta obyčejná aplikace s čísly dělá. Pokud by třeba
komprimovala data, určitě nechceš, aby autoři kompresní knihovny zvolili
tvůj přístup . Pokud
děláš nějaké triviálnější výpočty (průměry, střední hodnoty,
histogramy...), tak nastanou problémy na větších datech.
Takže spíš je třeba uvést příklad aplikace, která s čísly bude pracovat dostatečně málo.
U výpočtově náročnější aplikace může být dost velkým problémem fakt, že používá double. Po přepsání na inty lze dosáhnout zajímavých zrychlení, které v praxi rozhodují o tom, zda je použitelná (osobní zkušenost).
Zobrazeno 12 zpráv z 12.