Ideálny programovací jazyk

[nula]

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.

[Reklama]

[KarelI KarelI]

Ze se ale za tu RAM vzdycky tolik plati, kdyz si nekde porizujes virtualni server. Porovnej treba hostingy PHP vs Java No nevim nevim, do jake miry to porekadlo s vykonem a ram plati.

Ja jeste doted zadny svuj virtualni server nemam - protoze delam v Jave a stalo by me to tak moc penez, si neco jen tak ze srandy koupit...

Kdybych delal v PHP, tak mam hosting lusknutim prstu, protoze to stoji par slupek.

Prosimtě ty děláš jakoby to byly nějaký horentní sumy a jako kdyby java automaticky žrala nějaký giga. Virtuál s 2GB RAM stojí asi 1500kč/rok (to jsou 2 hodiny programátora). Já na tom provozuju web, mysql a java server, na který je připojeno několik set klientů, momentálně celý systém žere 375MB RAM.

[Cikáda]

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.

No nevím, proč  pořád používat shared_ptr, když je vlastní polygony.

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.

Tady se neshodneme na tom, že to v C++ poběží 10x pomaleji. Vývoj pravděpodobně trvat déle bude, ale výsledkem bude lepší kontrola nad pamětí i strojovým časem.
Jako jistě, pokud se k tomu přistupuje stylem "další cluster je levnější než to napsat líp", tak ano, ale ty zdroje nejdou škálovat donekonečna a někde ani škálovat nejdou.

Jinak jen aby bylo jasno, já nezpochybňuju GC, ani proti nim nic nemám. Ale zatracovat kvůli nim ostatní přístupy, které také mají nesporné výhody, mi přijde mimo.

[Kit]

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?

[nula]

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.

[Reklama]

[Kit]

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.

Jaký má tedy velikost DB vliv na spouštění GC? Podle mne to spolu nesouvisí. DB mohu mít velkou jak chci a na GC to nebude mít vliv.

[Cikáda]

...

Možná pomůže si znovu přečíst jeho příspěvek a všimnout si čárky.

[Kit]

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.

Otázka byla, jaké charakteristiky má aplikace, u které dělá problém spuštění GC. Odpovědí bylo, že větší databáze a aplikace citlivé na latenci. Ty citlivé aplikace chápu, ale ptám se: Proč ty větší databáze? Není jedno, zda má databáze 10 KB nebo 10 TB? Na GC aplikace to přece nemůže mít vliv.

[KarelI KarelI]

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žší.

[Cikáda]

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á...?

[Kit]

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ž polygon uvolní svůj node, tak všechny pointery na něj se stanou nefunkčními. Proto je zpravidla výhodnější shared_ptr. Při zániku polygonu zaniknou jen ty nody, které už nemají žádnou další referenci.

shared_ptr je vlastně mezivrstvou obsluhovanou na úrovni jazyka, syntaktickým cukrem. Když si to někdo chce obsloužit ve vlastní režii, ...

GC bych do toho netahal, ten s tím nemá nic společného.

[KarelI KarelI]

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”.

[Cikáda]

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”.

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"?

[Idris]

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á...?

tak si musím někde počítat reference, což je ještě horší než sharedptr.
GC to dělá mnohem efektivněji

Optimalizované počítání referencí bývá efektivnější, jednak se nic nepočítá, když čítač nepřekročí 1 (objekty s krátkou životností, obdoba nejnižší generace v tracing GC), a za druhé statická analýza odhalí případy, kdy není nutné čítač upravovat, i když by to dávalo smysl, například při návratu z funkce, kde se typicky dělá retain a následný (auto)release hned po sobě, což překladač odhalí a vyhodí. Kupříkladu Swift takto funguje a je to efektivnější než tracing GC. C++ má úplně jiný přístup s move sémantikou, ale to už tu psali jiní.

[KarelI KarelI]

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++.