Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Pokud vám komentáře neprocházejí, nejsou dostatečně přínosné a nechceme je proto pod článkem vydat.
Napište rozumné doplnění zprávičky/článku, ideálně podpořené odkazem a samozřejmě vám bude vydáno.
Jak se stará jen o živé? Ten overhead u GC nevadí? A proč by v C++ mělo být velmi drahé dělat krátce žijící objekty? Copak si nemůžu naalokovat paměť, kterou pak budu předávat, abych nemusel pořád alokovat a dealokovat?Kdysi jsem si potřeboval ověřit, jak moc v javě můžu prasit a bezohledně alokovat nové a vyšlo mi, že má asi desetinásobnou průchodnost proti MS C++. Čili za daný čas dokáže alokovat a zahodit 10x víc objektů než C++.
Tak zrovna MS C++ není úplně vypovídající. Také by mě zajímalo, jak jsi to měřil.
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.
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.
Když více polygonů vlastní jeden node, tak ho nemůžou mít přes unique, to je v rozporu.
Když tam budu dávat obyčejný pointer, tak si musím někde počítat reference, což je ještě horší než sharedptr.
GC to dělá mnohem efektivněji, v tom je ten vtip a to se tady už od včerejška snažím říci. Stručně řečeno, nepočítá reference, chodí jen po přeživších a má výraznou “množstevní slevu”.
Pokud více polygonů vlastní jeden node, tak už nejsou jeho, ale všech. Tj. to úplně neodpovídá tomu, co jsi na začátku psal. Takže ano, pak není shared_ptr od věci. Nebo se to taky dá udělat tak, jak jsem psal předtím - vlastnit to bude nějaká nadstruktura nad tím, která to v případě potřeby uklidí.
S tou efektivitou GC bych byl opatrný, protože hodně také záleží, jak funguje vevnitř. V čem přesně myslíš, že má "množstevní slevu"?
Když to bude vlastnit nadstruktura, tak jak pozná, že může vyhodit nepoužívané nody? Jasně, řešení známe, ptám se spíš proto aby sis rozmyslel, jestli to opravdu dovedeš řešit lépe než těmi sdílenými pointery.
Typický GC má "množstevní slevu" proto, že se nestará o nedosažitelné objekty, řeší jen živé. To znamená, že čím déle vydrží neběžet, tím víc bude těch mrtvých a tím víc na tom ušetří. V důsledku toho je velmi levné dělat krátce žijící objekty, což má spoustu dalších pozitivních důsledků. Naopak new/delete se poctivě stará o každý objekt, což je dost neefektivní a v důsledku nutí programátora, aby se krátkodobým objektům vyhnul.
Kdysi jsem si potřeboval ověřit, jak moc v javě můžu prasit a bezohledně alokovat nové a vyšlo mi, že má asi desetinásobnou průchodnost proti MS C++. Čili za daný čas dokáže alokovat a zahodit 10x víc objektů než C++.
Představ si to třeba jako když polygony vlastní své nody (a ty jsou sdíleny mezi sousedními polygony). Pokud bych měl evidenci (a tím i životnost) nodů řešit bokem tak to je přesně ten argument, který jsem dal na začátku.
No nevím, proč pořád používat shared_ptr, když je vlastní polygony.
Promiň, ale začíná mi připadat, že se nějak zásadně nechápeme ohledně využití shared_ptr.
Když je objekt "rovnocenně" vlastněn několika jinými, tak potřebuju evidovat, že ho stále někdo drží a až zmizí poslední vlastník, tak musí být uvolněn i ten objekt. Pokud mám GC, tak mi tuto evidenci pořeší a mám to bez práce. Pokud ne, tak se přímo k tomu nabízí shared_ptr, protože přesně tohle dělá, akorát je to dost drahé. Mohl bych si to dělat ručně někde bokem, ale v zásadě bych jen simuloval to počítadlo referencí co už je v tom shared, takže by to nejspíš bylo ještě dražší.
Ano, ale pokud polygony vlastní své nody, tak proč by je neměly vlastnit přes unique_ptr a ostatním dávat obyčejný pointer?
Ano, GC to za tebe pořeší a ty to máš bez práce... ale jak to ten GC pod kapotou asi dělá...?
Když více polygonů vlastní jeden node, tak ho nemůžou mít přes unique, to je v rozporu.
Když tam budu dávat obyčejný pointer, tak si musím někde počítat reference, což je ještě horší než sharedptr.
GC to dělá mnohem efektivněji, v tom je ten vtip a to se tady už od včerejška snažím říci. Stručně řečeno, nepočítá reference, chodí jen po přeživších a má výraznou “množstevní slevu”.
Představ si to třeba jako když polygony vlastní své nody (a ty jsou sdíleny mezi sousedními polygony). Pokud bych měl evidenci (a tím i životnost) nodů řešit bokem tak to je přesně ten argument, který jsem dal na začátku.
No nevím, proč pořád používat shared_ptr, když je vlastní polygony.
Promiň, ale začíná mi připadat, že se nějak zásadně nechápeme ohledně využití shared_ptr.
Když je objekt "rovnocenně" vlastněn několika jinými, tak potřebuju evidovat, že ho stále někdo drží a až zmizí poslední vlastník, tak musí být uvolněn i ten objekt. Pokud mám GC, tak mi tuto evidenci pořeší a mám to bez práce. Pokud ne, tak se přímo k tomu nabízí shared_ptr, protože přesně tohle dělá, akorát je to dost drahé. Mohl bych si to dělat ručně někde bokem, ale v zásadě bych jen simuloval to počítadlo referencí co už je v tom shared, takže by to nejspíš bylo ještě dražší.
...
Nemyslím to v situacích, kde by šel shared_ptr nahradit pomocí unique nebo move apod. Já se s tím běžně setkávám u grafových algoritmů, kde prostě není jeden vlastník objektu, ale je jich víc rovnocenných. V takovém případě buď použiju shared a daný objekt zmizí s posledním vlastníkem nebo bych si to musel evidovat někde bokem.
Tak je otázkou, jestli by se měly vrcholy vlastnit mezi sebou... U stromů to není problém, ale tam není problém použít unique_ptr. U jiných grafů si dovedu představit, že si je všechny držím v nějaké struktuře a mezi sebou mají jen pointery, nebo seznam id ostatních vrcholů. Se shared_ptr by mohl být problém např. u cyklů, když nad tím přemýšlím...
Představ si to třeba jako když polygony vlastní své nody (a ty jsou sdíleny mezi sousedními polygony). Pokud bych měl evidenci (a tím i životnost) nodů řešit bokem tak to je přesně ten argument, který jsem dal na začátku.
S GC mi stačí řešit přímo daný problém a VM se postará o výkon i paměť. V C++ mám na výběr - buď si ten GC musím pro každý algoritmus odsimulovat bokem abych se dostal na úroveň JVM, nebo využiju těch super vlastností C++11, ale poběží to třeba 10x pomaleji. To je ta údajná možnost volby. A tohle se v menší či větší míře děje všude, kde není k dispozici GC. Za to dostanu deterministickou dealokaci, kterou po mě v praxi ještě nikdo nechtěl.
Korektně musim dodat, že JVM přitom sežere násobně víc paměti, ale to mi přijde jako dobrý kompromis. Čas programátora a čas CPU jsou dražší než RAM.
Teď to neber špatně, ale když jsme tu diskutovali o JavaScriptu, tak standard ani dokumentace nebyly směrodatné, tak mě překvapuje, že máš potřebu to psát do dokumentace.To je nepochopení. Já jsem to vnímal tak, že ty argumentuješ, že "když je to v dokumentaci, tak to není problém - prostě RTFM!". Můj argument byl, že to je kontraintuitivní zhovadilost a to, že to je v dokumentaci, na tom nic nemění.
Souhlasím. Co takové std::optional v C++ ? To je taky "option navíc", nebo je to trošku dál?Nevím, C++ (už) neznám, ale obecně si myslím, že pokud Option není jediný způsob řešení "prázdných hodnot", tak jako by nebyl vůbec.
3. má homoikonická makra (ale v dokumentaci je palcovým písmem napsáno, že se nemají zneužívat tam, kde opravdu nejsou potřeba)
ad 6: Option "navíc", jako možnost, což u některých jazyků je, je k ničemu - pokud je null "občas někde", musím ho čekat všude a tímpádem Option ztrácí význam.
Problém je, že pokud někdo používá shared_ptr místo unique_ptr, resp. používá shared_ptr tak, že nechce řešit, kde co alokoval, jaká je scope a že by tedy občas měl udělat nějaký move, tak není C++ pro něj. To se to pak může fakt psát v té Javě.
Jen podotýkám, že nejsem žádný expert na C++, ale moc si nevzpomínám, kdy bych byl nucen použít shared_ptr.
Nemyslím to v situacích, kde by šel shared_ptr nahradit pomocí unique nebo move apod. Já se s tím běžně setkávám u grafových algoritmů, kde prostě není jeden vlastník objektu, ale je jich víc rovnocenných. V takovém případě buď použiju shared a daný objekt zmizí s posledním vlastníkem nebo bych si to musel evidovat někde bokem.
Ano, ale zdaleka ne všechny musí člověk používat. O tom je C++, neplatím za to, co nepoužívám. A nejkrásnější je na tom, že nikdo nikoho nenutí všechno používat. Takže opravdu se o to programátor starat nemusí.To co označuješ za výhodu (že se nemusí starat), lze z druhé strany nahlédnout jako nevýhodu (když se nepostará, tak nedostane). Stejně tak platí výkonem za to, že nepoužil co mohl.
Je to hezká teorie, ale v praxi spíš vidím, že C++ programátoři jsou řešením paměti úplně posedlí.
Proč by se nemělo pracovat se samotnými strukturami? Co je "hodnota třídy"?Tím jsem myslel strukturu na stacku, čili že se chová jako hodnota.
V jiných jazycích nejsou potřeba, ale jiné jazyky většinou neposkytují takový výkon.To je pointa celé mé úvahy, že ten výkon můžu klidně dostat tak, že to napíšu v jazyku, ve kterém nemusím řešit polovinu věcí, protože GC, to mi výrazně zjednoduší kód a ve výsledku to JIT zoptimalizuje líp, než bych to napsal v tom C++.
Tak shared_ptr většinou není moc proč používat. Pokud někdo používá shared_ptr, aby nemusel řešit životnost objektů, tak C++ fakt není pro něj. To je jako kupovat si Ferrari s tím, že s ním budu jezdit po poli...Teď mi to budeš muset lépe vysvětlit. Na jednu stranu zde čtu, že C++11 výrazně zlepšuje práci s pamětí (a snad chápu jak je to myšleno) a vzápětí říkáš, že shared_ptr není na životnost objektů. K čemu tedy je?
"Pokud někdo používá shared_ptr, aby nemusel řešit životnost objektů..."
shared_ptr není na životnost objektů.
...a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.
Naopak C++ je ve správě paměti od jedenáctky super. Člověk nad tím má kontrolu a přesto se o moc nemusí starat.Do jedenáctky byly dva způsoby jak objekt vytvořit a o něco více způsobů jak ho předat parametrem do funkce. Od C++11 je těch způsobů založení 4 a předání nesčetně více. To vše jsou věci, kde musí programátor dělat rozhodnutí, kde se to musí předělávat při refactoringu, kde se to musí nějak řešit při předávání do knihoven apod. Rozhodně bych tak komplexní věc nenazýval "...moc nemusí starat".
Tak bavíme-li se o algoritmu, tak předpokládám, že pracuji s nějakými "strukturami", které se alokují/dealokují samy. Od toho máme konstruktory a destruktory. Zrovna s algoritmy mám v C++ problém z jiných důvodů, než je správa paměti.V C++ se nepracuje se samotnými strukturami, ale s jejich hodnotami, odkazy, pointery (několika druhů) apod.
To sebou nese spoustu rozhodnutí, které v jiných jazycích nejsou vůbec potřeba, nemají (většinou) žádný vztah k řešenému problému a jsou vynuceny jazykem. Bohužel musím dodat, že to co se kde použije je u většiny programátorů čirý cargo cult.
Ony to ty "jiné jazyky" většinou dělají, ale jaksi "pod kapotou", tudíž když to neudělají dobře, tak to nemám jak ovlivnit.Naopak od C++11 se o to neni potreba starat a funguje to.
Na jednoduchých algoritmech možná ano, ale jak to začne být složitější, tak se ukáže, že shared_ptr mají netriviální režii, takže se to přepíše na kombinaci unique a raw pointerů, s tím související redesign aby byla pořešena životnost objektů atd. Prostě není pravda, že není potřeba se starat.
C++11 jasně ukazuje, že je špatný nápad tím prasit jazyk a že z toho cesta nevede. Smart pointery, move semantika atd. to ve výsledku ještě zhorší.
Ano. U jednoduchých algoritmů to moc nevadí, ale jakmile je to složitější, tak v konečném důsledku ten GC programátor píše pokaždé znova.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.