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

  • *****
  • 1 487
    • 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).

čumil

Re:Automatické uvolňování paměti v c++
« Odpověď #21 kdy: 20. 01. 2017, 21:09:24 »
To je nesmysl, to nejde.
Pouze čast stavu jde odhadnout za kompilace, zbytek ne protože je dán vnějšim stavem za běhu.

ARC je reference counting GC. Kompilator jen přidává reference county, nic vyc. V c++ se o to samé starají construktory a destruktory smart pointeru.

Rozhodně neexistuje GC ktere by proběhlo v compile time. Respektive, existuje.

Muselo by to ale mit schopnost predikovat budoucnost .......

čumil

Re:Automatické uvolňování paměti v c++
« Odpověď #22 kdy: 20. 01. 2017, 21:17:15 »
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Bohužel, problem s cykli a stuckem když se uvolňuje velký subgraph je tam furt.

I tak, pěkná konkurence dnešním generačním tracing monstrum.

Hezkej příklad síli statické analízi.

Ale není všemocná, to už si taky jednou v intelu mysleli, a pak to radši odpískali...

Sten

Re:Automatické uvolňování paměti v c++
« Odpověď #23 kdy: 20. 01. 2017, 21:26:31 »
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Možná tak u Hello World. V běžném programu je hodně objektů, které se likvidují v jiném scope, než kde vznikly. Kdyby se totiž všechny objekty likvidovaly ve stejném scope, tak vůbec není potřeba alokace na haldě (a nějaké GC) a všechny alokace by šlo vyřešit při kompilaci.

čumil

Re:Automatické uvolňování paměti v c++
« Odpověď #24 kdy: 20. 01. 2017, 22:10:01 »
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Možná tak u Hello World. V běžném programu je hodně objektů, které se likvidují v jiném scope, než kde vznikly. Kdyby se totiž všechny objekty likvidovaly ve stejném scope, tak vůbec není potřeba alokace na haldě (a nějaké GC) a všechny alokace by šlo vyřešit při kompilaci.
Dělal se pokus v Jave s podobnym GC, až 90% countu se odmazalo.

Jinak říkáš nesmysl ... Scope reference, ne objektu :)

Sten

Re:Automatické uvolňování paměti v c++
« Odpověď #25 kdy: 20. 01. 2017, 22:25:32 »
Dělal se pokus v Jave s podobnym GC, až 90% countu se odmazalo.

Jinak říkáš nesmysl ... Scope reference, ne objektu :)

Kde [em]se[/em] ten pokus dělal? Protože Java má něco podobného tak od 5ky.

Nikoliv, scope životnosti objektu. Pokud dostaneš referenci na existující objekt, tak ji musíš inkrementovat, jelikož ta předchozí může být z jiného threadu a během tvé práce zmizet

Sten

Re:Automatické uvolňování paměti v c++
« Odpověď #26 kdy: 20. 01. 2017, 22:28:31 »
Mimochodem jak optimalizace reference countingu souvisí s Javou, která je nemá?

zboj

  • *****
  • 1 487
    • Zobrazit profil
    • E-mail
Re:Automatické uvolňování paměti v c++
« Odpověď #27 kdy: 21. 01. 2017, 03:21:13 »
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Možná tak u Hello World. V běžném programu je hodně objektů, které se likvidují v jiném scope, než kde vznikly. Kdyby se totiž všechny objekty likvidovaly ve stejném scope, tak vůbec není potřeba alokace na haldě (a nějaké GC) a všechny alokace by šlo vyřešit při kompilaci.
Swift hlavně provádí escape analýzu (podobně jako Go) a co jde, dá na zásobník. U kolekcí je navíc hodnotová sémantika a CoW. U RC se navzájem vyruší release/retain u návratu z funkce a příslušného volání, takže RC se natvrdo mění jen u unikajících referencí, typicky v případě kolekcí.

Jerry

Re:Automatické uvolňování paměti v c++
« Odpověď #28 kdy: 21. 01. 2017, 09:21:45 »
Jestli hledáš C++, které má GarbageCollector (GC) tak je to verze ECMA C++/CLI a je normálně dostupná v MS VS 2003/5/8/10/13/15/17. Native ANSI C++ pochopitelně (GC) nemá. Takže když potřebuješ C++ s (GC) tak si musíš vybrat tu správnou verzi.  ;) Je nutné dodat, že C++/CLI je momentálně ze strany MS nepodporovaný protože má malou komunitu vývojářů a poslední plně
"funkční" verze je v MS VS 2008 C++/CLI SP2.

čumil

Re:Automatické uvolňování paměti v c++
« Odpověď #29 kdy: 21. 01. 2017, 09:41:53 »
Jestli hledáš C++, které má GarbageCollector (GC) tak je to verze ECMA C++/CLI a je normálně dostupná v MS VS 2003/5/8/10/13/15/17. Native ANSI C++ pochopitelně (GC) nemá. Takže když potřebuješ C++ s (GC) tak si musíš vybrat tu správnou verzi.  ;) Je nutné dodat, že C++/CLI je momentálně ze strany MS nepodporovaný protože má malou komunitu vývojářů a poslední plně
"funkční" verze je v MS VS 2008 C++/CLI SP2.
Nepotřebuješ nic od ms, to takhle boehm gc.

 

reklama