Zobrazit příspěvky
2161
Vývoj / Re:Ideálny programovací jazyk
« kdy: 12. 05. 2019, 15:40:59 »Ne každý tracing GC kopíruje, třeba v Go je normální alokátor a GC (tricolor) běží na pozadí a barví si objekty. A světe div se, je efektivnější než ten kopírující v Javě nebo .NET.Ano, můžeš zkoušet různé countery, vektory, předalokace, dealokace a věřit, že tím obejdeš nevýhody new/delete. Však si to někdy zkus. Můj první příspěvek byl právě o tom, že GC je v tomhle přinejmenším dobrý kompromis vzhledem k tomu, jak to usnadňuje práci programátora. Ano, namítáš, že C++ programátor si může vybrat, já říkám, že výkon tohoto mechanismu je tak mizerný, že u složitějších problémů je k tomu donucen.
Já si to zkoušel, ale přes unique_ptr. A nenamítám, že programátor v C++ si může vybrat, namítám, že GC není jednoznačnou výhodou a že ne-GC přístup má své nesporné výhody. Navíc nejprve by to chtělo specifikovat, co si představuješ pod pojmem "výkon".GC má samozřejmě overhead, ale když na něj dojde, tak často existuje jen zlomek objektů, co prošly tím programem. Pořeší tento zlomek a je hotovo. Delete se poctivě stará o každých pár byte co si někde alokuješ, to je prostě ohromný rozdíl.
Dělal jsem spoustu měření na různě složitých algoritmech. Pro lowlevel benchmark jsem si prostě udělal pole řádově tisíce pointerů a do toho jsem alokoval stále nové objekty. Ty něco triviálního počítaly a pak je přeplácnul nový objekt. Tohle samozřejmě GC chutná nejvíc, takže se tam projeví výhody proti delete.
Obávám se, že tohle nechápu. Zaprvé pokud existuje zlomek objektů, co prošly programem, tak proč bych měl v ne-GC přístupu alokovat víc? Zadruhé ten GC se taky stará o každý byte, protože nechce mít memory-leaky (a ten delete volá taky) - hlavní rozdíl je "kdy" a "jak často".
Ad ten příklad - pokud sis udělal řádově tisíce pointerů a do nich alokoval stále nové objekty, které něco počítaly a pak je přeplácnul, tak nechápu, proč jsi volal delete. Delete voláš až na konci, proč bych dealokoval paměť, kterou budu vzápětí alokovat? To potom chápu, že to pro GC vyházelo lépe, ale v takovém případě je problém jinde...
Účelem toho benchmarku bylo simulovat alokace v běžném programu. Tam jsou různé třídy a dělají různé věci. Tedy dává smysl alokovat různé objekty, k něčemu je použít a zase je smazat. Pokud bych to dělal jinak, tak bych netestoval to co jsem testovat chtěl.
Když už se pouštíš do debaty o GC, tak předpokládám, že aspoň zhruba víš jak funguje. Pro představu co se běžně používá - je kus paměti vyhrazen pro nové objekty, když tam dochází místo, tak živé (ty na které existuje odkaz) se vykopírují jinam a paměť se může znovu použít. Všimni si, že jsem vůbec nezmínil mrtvé objekty, pro ty se totiž nemusí dělat vůbec nic, žádný delete. V běžném programu je těch mrtvých v každé iteraci třeba 95%, takže je to proti klasickému delete výrazná úspora za cenu toho, že se musí 5% dat kopírovat.
