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.
Připomínám předmět vlákna. Bavíme se o ideálním jazyce. Ne o nejhorších možných, na které si člověk může vzpomenout. C, C++, JavaScript jsou všechno možné, jen ne nematoucí.
Java také nebude ten ideální jazyk...Kód: (Java) [Vybrat]public class HelloWorld
{
public static void main(String[] args)
{
Integer a = 1024;
Integer b = 1024;
System.out.print(a == b); // false
}
}
misto zbesileho raidu nad 4x USB-Flash bych pouzil raid nad 2x USB-SSD
1. ano a s mnohem lepsim iops
2. zkusenost s tim nemam ale treba tohle
3. pouzit industrialni microSD kartu (MLC chipy, Wear leveling, ECC korekce, SMART)
4. RPi slot na eMMC nema, protoze ho tam navrhar desky nedal (duvod: cena)
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.
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.
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?
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á...?
Možná pomůže si znovu přečíst jeho příspěvek a všimnout si čárky....
Docela mě zajímá, jaké charakteristiky má taková větší aplikace u které dělá problém spuštění GC.
Vetsi databaze, aplikace citlive na latenci.
Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.Popravdě jsem nikdy nedělal v Javě nic tak velkého. Zatím mi vždy stačil přístup napsat to jednoduše, hlavně pustit z hlavy poučky o mikro optimalizacích z C++ a v případě problému to zprofilovat.
Docela mě zajímá, jaké charakteristiky má taková větší aplikace u které dělá problém spuštění GC.
Vetsi databaze, aplikace citlive na latenci.
Odkdy má velikost databáze vliv na latenci GC?
Co to meles? Ja rikam neco jineho, ja rikam, ze velke db v jave s tim maji problem s gc, s world stopem, napr HBase, asi nejrozsirenejsi free big data databaze. A totez i aplikace citlive na latenci. Jakekoli spusteni GC znamena nedeterministicke lagy.
Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.Popravdě jsem nikdy nedělal v Javě nic tak velkého. Zatím mi vždy stačil přístup napsat to jednoduše, hlavně pustit z hlavy poučky o mikro optimalizacích z C++ a v případě problému to zprofilovat.
Docela mě zajímá, jaké charakteristiky má taková větší aplikace u které dělá problém spuštění GC.
Vetsi databaze, aplikace citlive na latenci.
A dalsi vec co nechapu proc to C++ dela je, ze kdyz chci vyuzivat jen stacku, tak pokud vracim z nejake funkce objekt na stacku, tak C++ ten objekt veme a cely ho prekopiruje jinam - nechapu proc, dyt je to neefektivni.
Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?
V cpp zadne rucni volani destruktoru neni potreba. Akorat lze presne zjistit kouknutim do kodu, kdy se tak stane.
Pokud jsem si všiml, tak destruktory fungují korektně jen v PHP. Spouští se ihned po uvolnění objektu. V ostatních jazycích je to slepeno dohromady s GC - destruktory neplní řádně svou funkci a proto je s nimi tolik potíží.
No nevím, ale v cpp jsem divné chování destruktorů nikdy nezaznamenal, zatím se mi vždy spustil bezprostředně po zavolání delete nebo když daný objekt má zmizet ze stacku. Pravdou je, že u jazyků používajících garbage collector tomu může být jinak, nicméně to bude asi jeden z důvodů, proč v Pythonu destruktory nejsou (měl by se spustit s během GC, což je nedefinovaný okamžik).
- Odstranit garbage collector, přidat ruční správu paměti a destruktory
Prosím ne. K Fortanu se nehodlám moc vyjadřovat, jen uvedu, že většina fortranového kódu, co jsem kdy viděl, byla neuvěřitelně zprasená, čímž jsem si k němu asi vytvořil doživotní odpor. Takže na „tvrdou“ numeriku používám C.
Movitz, tam bude hafo assembleroveho kodu ne?!!
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.
