Příspěvky

1

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 13:09:22 »

V této diskusi ovšem máme jiný problém – někomu něco vyhovuje, a myslí si, že to tedy musí být jediné správně řešení a vše ostatní je špatně. Všimněte si na rozdíl v našich argumentech. Vy argumentujete „je to špatně, protože já mám radši něco jiného“. Já argumentuju „tenhle přístup má tyhle výhody a tyhle nevýhody, výhodné je to pro tyhle případy; opačný přístup má tyhle výhody a tyhle nevýhody, výhodné je to pro tyhle případy“. Podle mne ten, kdo zabedněně lpí jenom na svém přístupu a považuje ho za jediný správný, jste tu vy.

Takdy ale vůbec nejde o to, co preferuje Filip Jirsák nebo někdo jiný. Důležité je, co očekává běžný Franta programátor od operátoru ==. Bežný Franta programátor očekává, že to bude porovnávat hodnoty a ne reference a už vůbec neočekává, že se to bude chovat pokaždé jinak podle kontextu. Proto je design operátoru == v Javě špatný, jednou to porovnává hodnoty, podruhé reference a běžný Franta programátor je z toho zmatený. Je úplně jedno, že Filipu Jirsákovi je křišťálově jasné, co to kdy dělá. Běžný Franta programátor v tom má hokej a dělá kvůli tomu zbytečné chyby.

To máš podloženo nějakým průzkumem? Klidně to může být tak, že běžný programátor od jednoduchého jazyka očekává, že == vezme to co má nejvíc po ruce a porovná to a nebude dělat žádnou magii. Když si uvědomíš, že reference je hodnota pointeru, tak to v obou případech dělá to samé - porovnává hodnoty. A možná je to přesně to, co od toho očekává běžný programátor.

2

Vývoj / Re:Ideálny programovací jazyk

« kdy: 15. 05. 2019, 15:51:24 »

To, že operátor == v Javě porovnává hodnoty primitivních typů a reference u objektů mi nijak neintuitivní nepřipadá.

Je to kontraintuitivni - jestlize o Jave nic nevim, muzu si rict tak leda "WTF" - vubec me nenapadne, proc by se to jednou melo chovat tak a jindy jinak.

Uz to samotne vase "jenom pro větší čísla" ukazuje na neco, co vypada divne. "Vetsi cisla"? To je co? Vime to? Je to nekde v dokumentaci? Nebo se to chova "nahodne" (podle toho, jak velky je zrovna ten pool)?

Kdo o Javě nic neví, tak musí pochopit, že == na objektech porovnává reference. A že pokud porovnává objekty, které neudělal, tak je to implementačně závislá věc. Ten efekt se může dít u jakékoli knihovny apod.

Myslím, že u jakékoli jiné implementace toho operátoru bych musel napsat mnohem víc, abych vysvětlil jeho chování. A že takové jazyky máme a jsou i rozšířené :-)

3

Vývoj / Re:Ideálny programovací jazyk

« kdy: 15. 05. 2019, 12:09:22 »

Franta má 1024 Kč, Pepa má také 1024 Kč. Pepa je Franta.

No jenže pokud ale mají oba pouze 50 Kč, pak opravdu jo:

Kód: (Java) [Vybrat]

public class HelloWorld
{
  public static void main(String[] args)
  {
    Integer a = 50;
    Integer b = 50;
    System.out.print(a == b); // true
  }
}


Nemá smysl se vrtat v těchle profláklejch kravinkách. Každej jazyk a platforma co má něco za sebou obsahuje takovýhle věci, protože co se zdálo dobré tenkrát se za 10 - 20 let ukáže jako špatné rozhodnutí. Java si tím prošla několikrát a už má nasbíráno pěknou řádku kostlivců, na druhou stranu pořád to není tak hrozný právě kvůli její jednoduchosti. Podívej se na specifikaci rovnosti v javascriptu, pochybuju, že řadový JS programátor by to dal dohromady. Podívej se na chytáky v C#, tam to chvíli trvalo, než třeba lambdy udělali blbuvzdorný.

Na jednu stranu můžeme jakožto líní programátoři žádat, aby byl jazyk jednoduchý a bez nástrah, na druhou stranu to vždy bude něco za něco a holt by zatím člověk neměl otevřít editor dokud si nenačte jak se chová rovnost, spojování stringů, přetypování na bool, hashe a equals apod. To jsou věci, který jsou snad v každym jazyku jinak a dost často nějak blbě.

4

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 13:26:08 »

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.

To je teda hodně debilní benchmark.

Chápu, že jsi nemusel pochopit motivaci k takovému lowlevel benchmarku, ale stačí se zeptat, nemusíš tady hned vylévat své frustrace.

5

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 13:24:59 »

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.

6

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 10:48:38 »

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.

Tak tam záleží, jak to bude navrhnuto. Ale typicky přes counter, nebo nějaký vektor. Myslím, že rychlostně by si člověk mohl pomoct.

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?

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.

7

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 23:13:11 »

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.

No, ono 100x nic zabilo vola. Ja si myslim, ze na vykonu a zravosti zalezi. Je to o tech detailech. Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.

A kde ti to stoji 1500,- za rok? U active24 je VPS 2GB za 400,- mesic, mel jsem VPS u Forpsi, tam jsem mel jen 1GB a stalo to pulku. Tak to by me zajimalo, kde jsi narazil na takovy kauf - 2gb jen za 1500,-. Moc ti neverim.

Nevím, spring nepoužívám. A pokud to je líný, tak tím spíš to nepoužiju.

Virtuál mám u Wedosu. V akci to bývá nějakých 800 ročně, jinak kolem těch 1500.

8

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 22:51:56 »

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

9

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 20:13:05 »

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

10

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 19:19:57 »

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

11

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 15:46:57 »

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.

12

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 14:40:05 »

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.

13

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 01:32:30 »

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.

14

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 00:40:45 »

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.

15

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 00:33:48 »

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

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?