reklama

Automatické uvolňování paměti v c++

Re:Automatické uvolňování paměti v c++
« Odpověď #15 kdy: 10. 01. 2017, 18:42:00 »
Záleží, zda-li potřebuješ tolik konektorů pro disky.
Když už, tak bych šel do osmijádrový varianty:
http://www.vmshop.cz/MBD-A1SAM-2750F-O/a1sam-2758f-o-atx-avoton#ok
Nestojí o moc víc...
Samozřejmě je víc edic a modelů s osmijádrem, takže určitě něco bude mít i víc portů.

reklama


Re:Automatické uvolňování paměti v c++
« Odpověď #16 kdy: 10. 01. 2017, 18:48:01 »
Oops, sorry...Špatnej topic...

Kdo iv

Re:Automatické uvolňování paměti v c++
« Odpověď #17 kdy: 10. 01. 2017, 20:15:13 »
Automatickemu pridanu brani "zero overhead principle" C++ ze ziadna feature nesmie brat vykon pokial ju nepouzivate. Reference counting pridava overhead takze nie je zapnuty by default.

Jen dodam, ze thread-safe reference counting ma jeste vetsi overhead. A tady uz tezko muze kompilator rozhodnout jak a jestli vubec zamykat.
Ten overhead závisí na konkrétní architektuře, některé to umí hodně rychle. Navíc překladač (resp. optimizér) často pozná, že není nutné RC měnit (obdoba escape analysis).

Nejaka mereni, kde se da toto overit? Ne ze bych ti neveril spis naopak (take si myslim ze by ta rezie dnes nemusela byt tak silena a ze se toho nekteri jen zbytecne moc boji).

Jinak to stim ze to eliminuje pocet incrementaci a dekrementaci je pravda ale opet nevim jak moc jsou dnesni kompilatory uspesne, vim ze je to jeden z cilu jazyka D, zlepsit statickou analyzu aby bylo mozne implementovat rychly RC, ktery zaroven bude memory safe.

atarist

Re:Automatické uvolňování paměti v c++
« Odpověď #18 kdy: 10. 01. 2017, 23:38:20 »
Nejaka mereni, kde se da toto overit? Ne ze bych ti neveril spis naopak (take si myslim ze by ta rezie dnes nemusela byt tak silena a ze se toho nekteri jen zbytecne moc boji).

No a nebo to taky muze dopadnou hodne spatne - cim vic jader, tim vetsi problem s tou casti kodu, ktera nepobezi paralelne. Podle me to bez spoluprace s programatorem asi nepujde. Treba Rust to resi tak, ze donuti programatora presne specifikovat, co a jak se pouziva. Potom dokaze vygenerovat efektivni kod.

Nejde ani tak o to, ze rezie jednoho atomickeho ++ nebo -- (a testu na nulu) by byla silena, ale v tom, ze se bude provadet dost casto.

Re:Automatické uvolňování paměti v c++
« Odpověď #19 kdy: 11. 01. 2017, 00:46:06 »
Co brání v C++ tomu, aby byly do kódu vloženy automaticky řádky pro uvolnění již nevyužitelných zdrojů v čase kompilace? Je to pŘece deterministický úkol, až na nějaké speciální případy je známo, kde je potřeba paměť uvolnit. Proč to teda musí programátor psát ručně?
Nic, tohle C++ dávno má, říká se tomu destruktor a překladač ho tam vkládá automaticky. Programátor jen napíše, jakým způsobem se ty zdroje úvolní

A z jiného soudku, proč má třeba Java ještě pořád GC, když uvolňování zdrojů lze předvídat už v čase kompilace? GC přece zbytečne spotřebovává paměť a čas procesoru, tak nač?
Skutečně? Nejsem si jist.

Příklad kde to už existuje: Objective-C a Automatic References Counter.
ARC fungují jen když sdílíte immutable objekty. Pak mohou být i MT Safe. Jakmile ale můžete dodatečně měnit linky v již vytvořených objektech, pak umíte vytvořit cyklus a ten ARC uvolnit neumí.

Mimochodem, ARC je i v C++. Buď shared_ptr, nebo se dá napsat jednoduché řešení s counterem uvnitř objektu. Oba systémy mají své výhody a nevýhody.


zboj

  • *****
  • 854
    • Zobrazit profil
    • E-mail
Re:Automatické uvolňování paměti v c++
« Odpověď #20 kdy: 11. 01. 2017, 13:17:28 »
Automatickemu pridanu brani "zero overhead principle" C++ ze ziadna feature nesmie brat vykon pokial ju nepouzivate. Reference counting pridava overhead takze nie je zapnuty by default.

Jen dodam, ze thread-safe reference counting ma jeste vetsi overhead. A tady uz tezko muze kompilator rozhodnout jak a jestli vubec zamykat.
Ten overhead závisí na konkrétní architektuře, některé to umí hodně rychle. Navíc překladač (resp. optimizér) často pozná, že není nutné RC měnit (obdoba escape analysis).

Nejaka mereni, kde se da toto overit? Ne ze bych ti neveril spis naopak (take si myslim ze by ta rezie dnes nemusela byt tak silena a ze se toho nekteri jen zbytecne moc boji).

Jinak to stim ze to eliminuje pocet incrementaci a dekrementaci je pravda ale opet nevim jak moc jsou dnesni kompilatory uspesne, vim ze je to jeden z cilu jazyka D, zlepsit statickou analyzu aby bylo mozne implementovat rychly RC, ktery zaroven bude memory safe.
Podrobně o tom píšou v dokumentaci k Objective-C. V jazycích majících struct pak ten problém prakticky mizí, ve Swiftu se režie neprojeví (aspoň na amd64, na ARM jsem netestoval).

 

reklama