Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: vyvojar 02. 08. 2015, 22:48:14
-
Nemám zrovna velkou zkušenost s C++ co se týče nějakých větších projektů (jazyk jako takový ovládám myslím celkem solidně).
Pokaždé když jsem ale něco většího dělal, tak jsem poměrně dost částu trávil tím, že jsem přemýšlel, jestli mám vracet hodnotou nebo ukazatel, kdo pak uvolní pameť atd.. V podstatě to vždycky vede na použití shared pointrů, které čítají reference a objekt uvolní, když už na něj žádná reference neexistuje. Nevýhodou shared pointrů je, že se pro to čítání referencí používají atomické instrukce (compare and swap) a ty jsou přece jenom o něco ménně efektivní.
No co tím chcí říct, jestli má cenu vůbec používat C++, pokud tedy nejde o projekt, který opravdu vysloveně potřebuje ze železa vyždímat úplné maximum.
Dlé mého názoru je daleko lepší použití Javy, protože JVM se posouvá dál a dál a čím dál tím víc se výkonnost blíží jazykům, které se překládají přímo do nativních instrukcí procesoru. Samozřejmě ať každý používá co umí a v čem se mu dělá lépa, ale objektivně kdy má cenu volit C++?
-
Odpověděl sis sám. Na všechno velké je Java ideální. Výkon luxusní a celkově to má vše, co bys našel jinde. C++ je pro honibrky na fórech, ale reálně je to s ním horší.
-
objektivně kdy má cenu volit C++?
-lowlevel. Konkretnu instrukciu v Jave nezavolas.
-nativne API v Jave priamo nezavolas, zostava ti JNI a to zase pada k niecomu kompilovanemu. Ked ma program spajat alebo intenzivne vyuzivat C API, tak to nema zmysel robit v Jave
-praca s resourcami, ak je jej vela. V C++ sa premenne destruuju, ked vyjdu zo scope. V Jave nic take automaticke nie je a programator si to musi vzdy osetrit, takze tam lahsie spravi chyba. (Finalizer je v tomto zmysle nanic, kedze sa nemusi zavolat)
-predpovedatelnost. V Jave sa sice da napisat aj herny engine aj kodek videa, ale obidve da dost prace, aby to pri GC bezalo plynule.
-
Alternativně lze místo Javy použít C# - pro nízkoúrovňový kód máte k dispozici i ukazatele a ruční alokaci paměti.
V C++ sa premenne destruuju, ked vyjdu zo scope.
Což je užitečné pouze v případě, kdy je životnost zdroje vázána na scope.
Finalizer je v tomto zmysle nanic, kedze sa nemusi zavolat
Destruktor se rovněž nemusí zavolat.
predpovedatelnost
To také nemusí být tak jednoduché - např. při lavinovitém uvolňování paměti (musíte to rozdělit, což GC v Javě udělá za vás).
-
Tak co se memory managementu týče, C++ je jednoznačně rychlejší, na tom se snad shodneme. Jestli to má být náročná aplikace, tak bych C++/C určitě zvážil. Celkově si prostě kvůli výkonu radši vyberu C/C++ aplikaci než něco v Javě. Ale je to něco za něco... když se vám runtime stará o paměť, tak se samozřejmě vyvíjí snáz. Jestli to je něco co se bude neustále vyvíjet a kde je rychlost vývoje důležitá, Javu bych zvážil.
-
Ta otázka je položena dost nešťastně. Nelze to rozhodnout bez dalších znalostí o projektu a týmu. Jako člověk, který rozhoduje o tom, jestli zvolit Javu nebo C++, bys měl projít zhruba takovou úvahou:
Poběží to na serveru? Java
Poběží to na klientovi? C++
Potřebuju, aby to mělo definované latence? C++
Je mi jedno, že se to občas na nějakou dobu zasekne? Java
Potřebuju, aby to bylo co nejvíc portabilní a běželo to i na slabém HW? C(++)
Vědí ostatní programátoři v týmu, co je to pointer? Ne? Java
Vědí co je to pointer, ale naposledy ho použili ve škole, když dělali semestrálku? Java
Půlka týmu si raději vezme dovolenou, když zaslechne slova segfault, coredump a gdb? Java
Hodí se mi nějaká technologie/framework, kterou přímo nabízí C++ nebo Java?
Další body do rozhodovací tabulky si už doplň podle konkrétního projektu.
-
Pujde na neco pouzit rozsahla knihovna dostupna jen v jave? Java
-
Řekl bych, že tím cos napsal sis odpověděl už sám - asi ti zbývá jen ta Java.
-
C++ je poněkud náročnější na programátora. Výhodou Javy je GC a knihovny. Nicméně pokud je k dispozici dobrý programátor, lze z C++ vyždímat víc.
-
Potřebuju, aby to mělo definované latence? C++
V Javě můžete použít real time GC.
V C++ si naopak musíte pohlídat již zmíněné lavinovité uvolňování paměti (real time GC to pohlídá za vás).
-
Tak co se memory managementu týče, C++ je jednoznačně rychlejší, na tom se snad shodneme.
Paměť pro některé datové struktury může být rychlejší spravovat pomocí GC (samozřejmě v C++ si GC můžete implementovat, nicméně pohodlnější může být použít nějaký jazyk s GC).
-
Tak co se memory managementu týče, C++ je jednoznačně rychlejší, na tom se snad shodneme. Jestli to má být náročná aplikace, tak bych C++/C určitě zvážil. Celkově si prostě kvůli výkonu radši vyberu C/C++ aplikaci než něco v Javě. Ale je to něco za něco... když se vám runtime stará o paměť, tak se samozřejmě vyvíjí snáz. Jestli to je něco co se bude neustále vyvíjet a kde je rychlost vývoje důležitá, Javu bych zvážil.
No já jsem slyšel, že GC v HotSpot je vůbec nejrychlejší memory management (tzn. by měl být i efektivnější než implementace malloc). Těžko říct, jak to objektivně nějak srovnat. Asi celkový čas strávený alokacemi/dealokacemi u nějakého většího programu je nejmenší. Padlo to někde v přednášce "Understanding Java Garbage Collection", co byla na Java One 2014 konferenci.
-
Což je užitečné pouze v případě, kdy je životnost zdroje vázána na scope.
Ve kterém případě není životnost zdroje vázána na některý scope?
-
Ve kterém případě není životnost zdroje vázána na některý scope?
Nejde o to, jestli na některý, ale jestli na nějaký konkrétní.
-
Což je užitečné pouze v případě, kdy je životnost zdroje vázána na scope.
Ve kterém případě není životnost zdroje vázána na některý scope?
Často je vázána na nějakou událost. Například soubor / databázi můžete chtít zavřít, když všichni (nebo někteří) klienti uzavřou spojení. Nebo píšete asynchronní výpočet pomocí callbacků. Pokud netrváte přímo na zdrojích, tak dalším příkladem jsou různé dokazovače, které odvozují formule v logice - když například odvodíte, že musí platit formule (A nebo B), a poté odvodíte, že musí platit A, tak formuli (A nebo B) můžete odstranit - tj. životnost (A nebo B) končí v okamžiku, kdy jste odvodil A.
-
C++ vyzaduje hodne discipliny a je narocny dodrzet stejnou metodologii v celym tymu. Vsechen komercni sw v C++ kterej jsem videl, byl prasacky Ccko se tridama - s opravdovym C++ to nemelo nic spolecnyho. Asi to bylo tim, ze ten kod byl hodne starej, ze dneska moc novych projektu nevznika.
Navic samotny C++ zadnou rychlost negarantuje. Staci jedno nechteny predavani promenne hodnotou (misto reference) a cely kod muze byt pomalejsi nez v Jave. Pred rokem jsem neco fixoval v generatoru parseru ANTLR (neco jako bison). Predhodi se tomu gramatika jazyka a ono to vygeneruje zdrojaky parseru v Jave, C++, Pythonu, ... Zajimavy bylo, ze parser v Java byl cca 2x rychlejsi nez ten v C++. Pritom vygenerovany zdrojaky byly na prvni pohled naprosto identicky. Stejny tridy, metody, podminky, switche. Trvalo mi to dost dlouho nez jsem to srovnal a ted je C++ target 2x rychlejsi nez Java. Problem byl v memory managementu, od verze 1.7 umi Java opravdu rychle alokovat a uvolnovat objekty ktere ziji jen kratce. Samozrejme, ze C++ RAII je jeste rychlejsi, ale musi se to spravne pouzit. Dalsi problem byl v poradi vyhodnocovani jedne podminky - misto "if ( a() = true && b() = true)" to bylo obracene a "b()" bylo velice narocne na vyhodnoceni.
Takze pokud te bavi programovani a ches mit vsechno pod kontrolou, tak pouzij C++. Pokud chces nadelat velky prachy tak pouzij Javu.
-
V jedné staré knize o softwarovém inženýrství byl jako jeden z podstatných kroků při úvahách o novém projektu uveden bod nazvaný „volba vhodného programovacího jazyka”. Lidem ještě v těch dobách bylo jasné, že každý jazyk se hodí na trochu něco jiného.
A za mě – od té doby, co vymysleli Javu, je C++ úplně k ničemu a u nových projektů bych ho v žádném případě nezvažoval. V dnešní době má cenu zvažovat C u low-level projektů, má cenu zvažovat Fortran pro náročné výpočty, ale C++ bych se raději vyhnul, protože nepřináší nic, co by nenabízely i jiné jazyky mnohem pohodlnější formou. C++ je něco jako MS–DOS – tedy takový evoluční omyl, beznadějně zastaralý a překonaný už v době svého vzniku, který znepříjemňoval lidem život ještě dalších 15 let.
-
V jedné staré knize o softwarovém inženýrství byl jako jeden z podstatných kroků při úvahách o novém projektu uveden bod nazvaný „volba vhodného programovacího jazyka”. Lidem ještě v těch dobách bylo jasné, že každý jazyk se hodí na trochu něco jiného.
Bjarne Stroustrup odpovida na otazku, zda delat projekty v C++: mas li projektovy tym lidi, kteri ovladaji Cobol, delej ten projekt v Cobolu
ale C++ bych se raději vyhnul, protože nepřináší nic, co by nenabízely i jiné jazyky mnohem pohodlnější formou...
napr. v GUI oblasti existuji frameworky, ktere jsou napsany v C++ a zde je pak skutecne tezke, se rozhodnout proti C++. Pak uz zbyva jen implementace takoveho frameworku (toolkitu) do nejakeho interpretru, coz je spojeno vzdy s mensimi i vetsimi problemy.
A kdyz uz jste vzpomenul ty stare casy, tak Kernighan vzdy rikal, ze C nebyla vyvinuta, aby se v ni delaly velke projekty, nybrz na tvorbu domenovych nastroju, kterymi se ty velke projekty pak delaji.
-
A proč neudělat kritický části v C/C++ a celý to pak slepit třeba Pythonem? V čem by bylo tohle řešení obecně méně výhodné, než Java? Java mi přijde nejvýhodnější jenom na serveru.
-
Což je užitečné pouze v případě, kdy je životnost zdroje vázána na scope.
Ve kterém případě není životnost zdroje vázána na některý scope?
Často je vázána na nějakou událost. Například soubor / databázi můžete chtít zavřít, když všichni (nebo někteří) klienti uzavřou spojení. Nebo píšete asynchronní výpočet pomocí callbacků. Pokud netrváte přímo na zdrojích, tak dalším příkladem jsou různé dokazovače, které odvozují formule v logice - když například odvodíte, že musí platit formule (A nebo B), a poté odvodíte, že musí platit A, tak formuli (A nebo B) můžete odstranit - tj. životnost (A nebo B) končí v okamžiku, kdy jste odvodil A.
Kdyz klient uzavre spojeni, tak se zdestruuje, a protoze drzi shared pointer na databazi, tak s poslednim klientem se zavre i databaze, ze :)
-
A proč neudělat kritický části v C/C++ a celý to pak slepit třeba Pythonem? V čem by bylo tohle řešení obecně méně výhodné, než Java?
V tom, ze Python ma GIL a zjevne se s tim nic moc delat nebude. Coz je v 21. stoleti ponekud trapne :)
-
Což je užitečné pouze v případě, kdy je životnost zdroje vázána na scope.
Ve kterém případě není životnost zdroje vázána na některý scope?
Často je vázána na nějakou událost. Například soubor / databázi můžete chtít zavřít, když všichni (nebo někteří) klienti uzavřou spojení. Nebo píšete asynchronní výpočet pomocí callbacků. Pokud netrváte přímo na zdrojích, tak dalším příkladem jsou různé dokazovače, které odvozují formule v logice - když například odvodíte, že musí platit formule (A nebo B), a poté odvodíte, že musí platit A, tak formuli (A nebo B) můžete odstranit - tj. životnost (A nebo B) končí v okamžiku, kdy jste odvodil A.
Kdyz klient uzavre spojeni, tak se zdestruuje, a protoze drzi shared pointer na databazi, tak s poslednim klientem se zavre i databaze, ze :)
Ano, ale to už životnost zdroje není vázána na obor platnosti nějaké proměnné. Navíc to funguje dobře pouze pro jednoduché situace - např. můžeme přidat pravidlo, že zdroj se má uvolnit, po odpojení posledního klienta, pokud se po dobu 30 sekund nikdo nepřipojí.
Kromě toho shared_ptr, tj. naivní počítání referencí, je z hlediska výkonu často mnohem horší (http://flyingfrogblog.blogspot.cz/2011/01/boosts-sharedptr-up-to-10-slower-than.html) než třeba Mark & Sweep (například, když k tomu zdroji budete velmi často přistupovat). Navíc si musíte hlídat cykly.
-
Nemám zrovna velkou zkušenost s C++ co se týče nějakých větších projektů (jazyk jako takový ovládám myslím celkem solidně).
Pokaždé když jsem ale něco většího dělal, tak jsem poměrně dost částu trávil tím, že jsem přemýšlel, jestli mám vracet hodnotou nebo ukazatel, kdo pak uvolní pameť atd.. V podstatě to vždycky vede na použití shared pointrů, které čítají reference a objekt uvolní, když už na něj žádná reference neexistuje. Nevýhodou shared pointrů je, že se pro to čítání referencí používají atomické instrukce (compare and swap) a ty jsou přece jenom o něco ménně efektivní.
No co tím chcí říct, jestli má cenu vůbec používat C++, pokud tedy nejde o projekt, který opravdu vysloveně potřebuje ze železa vyždímat úplné maximum.
Dlé mého názoru je daleko lepší použití Javy, protože JVM se posouvá dál a dál a čím dál tím víc se výkonnost blíží jazykům, které se překládají přímo do nativních instrukcí procesoru. Samozřejmě ať každý používá co umí a v čem se mu dělá lépa, ale objektivně kdy má cenu volit C++?
C++ ma cenu v pripade ze potrebujes pouzivat nejake dalsi subsystemy ci knihovny ktere maji jen c++ rozhrani. Jinak pokud je potreba vykon tak je idealni pouzit jazyk D. Ten je idealni kombinaci jak javy (GC, velmi podobny OOP model) tak C++ (vykon).
-
Kromě toho shared_ptr, tj. naivní počítání referencí, je z hlediska výkonu často mnohem horší (http://flyingfrogblog.blogspot.cz/2011/01/boosts-sharedptr-up-to-10-slower-than.html) než třeba Mark & Sweep (například, když k tomu zdroji budete velmi často přistupovat). Navíc si musíte hlídat cykly.
Přístupy nevadí. Vadí kopírování toho smart pointeru, což je spíš předávání vlastnictví toho zdroje. Zamyslet se nad vlastnictvím objektů je v C++ dost kritické.
V tom odkazovaném testu vidím zádadní zádrhele. Hned v prvních komentářích mu tam vytýkají že je to strukturované nějak divně a autor přiznává že vyšel z automaticky generovaného kódu. Pokud se kód navrhne stejně jako v jazycích s GC, kde je předávání silných ukazatelů prakticky zadarmo, tak to samozřejmě dopadne špatně.
Jo, chytré ukazatele mají svoje zádrhele, ale tenhle test bych zobecňoval hodně opatrně.
-
V tom, ze Python ma GIL a zjevne se s tim nic moc delat nebude. Coz je v 21. stoleti ponekud trapne :)
[/quote]
Trapný to je, ale když to člověk vezme pragmaticky -
- python jako glue (formuláříky, okýnka, odstartovávání nativních rutin...) - k tomu přeci není třeba usilovat o využití všech jader na plný plyn
- na spuštěnou C++ nativní rutinu si už žádný GIL nepřijde
... takže ve výsledku můžu mít aplikaci, kdy do pythonovskýho formuláříku klepu vstupní data a na pozadí mi X céčkových subrutin roztáčí větrák na plný plyn, nebo mi něco uniká?
-
Trapný to je, ale když to člověk vezme pragmaticky -
- python jako glue (formuláříky, okýnka, odstartovávání nativních rutin...) - k tomu přeci není třeba usilovat o využití všech jader na plný plyn
Prave naopak - v GUI aplikacich dobry multithreading vyuzijes paradne, protoze kdyz na neco kliknes a ono se tam neco prepocitava, tak nechces, aby ti GUI zamrzlo. U by-design unithreadovych jazyku to pak musis ruzne obchazet, coz je zbytecna namaha. Z hlediska programatora to muze byt neviditelne schovany nekde v hloubce nejakych knihoven, ale opruz to je a dusledky to ma i tak, i kdyby jenom v tom, ze je vyvoj knihoven pomalejsi a nekompatibilni zmeny API castejsi.
- na spuštěnou C++ nativní rutinu si už žádný GIL nepřijde
Pokud se GIL spravne releasuje, tak ne, ale zase: musi se na to myslet, je to uplne zbytecnej opruz.
Treba ted je desne cool pouzivat Python pro zpracovani dat (pandas atd.) a kazdou chvilku nekdo prijde s tim, ze nejakou CAST nejakeho vypoctu udelal s releasnutym GILem a vypocet se zrychlil o stovky procent. No to je parada, ale dela se to ad hoc, misto aby se to nemuselo resit vubec, nebo aspon nejak inteligentnejc.
... takže ve výsledku můžu mít aplikaci, kdy do pythonovskýho formuláříku klepu vstupní data a na pozadí mi X céčkových subrutin roztáčí větrák na plný plyn, nebo mi něco uniká?
Ano, pokud na to myslis, patricne knihovny to podporuji a jsou prelozene s patricnymi optionami, udelal jsi kolem serveru kridou pentagram a obetoval panenskeho holuba :)
-
Kromě toho shared_ptr, tj. naivní počítání referencí, je z hlediska výkonu často mnohem horší (http://flyingfrogblog.blogspot.cz/2011/01/boosts-sharedptr-up-to-10-slower-than.html) než třeba Mark & Sweep (například, když k tomu zdroji budete velmi často přistupovat). Navíc si musíte hlídat cykly.
Přístupy nevadí. Vadí kopírování toho smart pointeru
To je pravda.
V tom odkazovaném testu vidím zádadní zádrhele. Hned v prvních komentářích mu tam vytýkají že je to strukturované nějak divně a autor přiznává že vyšel z automaticky generovaného kódu.
Na druhou stranu to v těch komentářích zkoušelo několik lidí vylepšit a výsledný kód byl stále 4x pomalejší než v OCamlu.
Já nepochybuji, že v C++ napíšete minimálně stejně rychlý kód jako v C# nebo v Javě - koneckonců VM těchto jazyků také bývají implementována v C++ - otázkou spíše je, jaké úsilí pro to musíte vyvinout. Například psát asynchronní kód ve standardním C++ je IMO dnes těžší než v C# (jak například uvolnit paměť, když asynchronní výpočet nikdy nedoběhne - v C# tohle řešíte pouze pro zdroje, ostatní paměť uvolní GC), podobně napsat soft real-time systém v C++ nemusí být vůbec jednoduché a GC v Erlangu, Go nebo některých implementacích Javy to může usnadnit. Stejně tak, jaké jsou například garance, že se v C++ vykoná destruktor (například když není pro jeho vykonání dost místa na zásobníku)? V C# můžete finalizaci garantovat pomocí CriticalFinalizerObject.
-
Na druhou stranu to v těch komentářích zkoušelo několik lidí vylepšit a výsledný kód byl stále 4x pomalejší než v OCamlu.
Tak to holt dopadá, když je blbě už návrh. Linked list pomocí smart pointrů je fakt blbý nápad, ale aby se ho zbavili, tak by to museli komplet přepsat.
jak například uvolnit paměť, když asynchronní výpočet nikdy nedoběhne - v C# tohle řešíte pouze pro zdroje, ostatní paměť uvolní GC
Tohle je přesně důvod, proč nemám rád GC. Paměť je jen jeden ze zdrojů. GC tak řeší jen jeden aspekt úklidu a všechno ostatní mi zůstane na krku. Smart pointery řeší všechno úplně stejně jako paměť. Akorát jsou tam samozřejmě jiné mouchy.
Nevím, jak dobře se pracuje s asynchronním kódem v C#, ale s ASIO je to v C++ celkem pohoda. I bez lambda funkcí se ke callbackům dá všechno potřebné přibalit pomocí std::bind. Úklid pak řeší destruktor toho callbacku.
Jinak fakt nechci zabíhat do diskuzí o tom, který jazyk je rychlejší. Vím jak to dopadá. Chtěl jsem jen upozornit na to, že ten benchmark neměřil pomalost C++ ale špatně použitých smart pointerů a datové struktury která se do C++ moc nehodí.
-
Prave naopak - v GUI aplikacich dobry multithreading vyuzijes paradne, protoze kdyz na neco kliknes a ono se tam neco prepocitava, tak nechces, aby ti GUI zamrzlo. U by-design unithreadovych jazyku to pak musis ruzne obchazet, coz je zbytecna namaha....
Souhlasím, že v GUI aplikacích to využiju parádně, moje vyjádřená pochybnost (Python jako lepidlo) se však týkala jen grafické vrstvy GUI aplikace. Proto nekliknu a nepřepočítává... po kliknutí se spustí nativní aplikace, jejíž procesorový čas řídí OS a ne Python. Zatímco já si povídám skrz guiksicht s Pythonem, nativní aplikace vyřeší multiprocesorově problém a výsledek přichystá Pythonu na podnose, kde si ho příležitostně vyzvedne a použije v komunikaci se mnou.
Pokud se GIL spravne releasuje, tak ne, ale zase: musi se na to myslet, je to uplne zbytecnej opruz.
Buď si nerozumíme, nebo to blbě chápu... domnívám se, že té nativní aplikaci je GIL úplně ukradený, protože ta si hraje na svém písečku - jako bych třeba z Pythonu pustil wget na nějakej pornoserver :-)
-
Smart pointery řeší všechno úplně stejně jako paměť. Akorát jsou tam samozřejmě jiné mouchy.
Ano, třeba zvýšené nároky na paměť, pokles výkonu, záseky programu při uvolňování, občasné úniky paměti a zdrojů (při cyklech).
Tohle je přesně důvod, proč nemám rád GC. Paměť je jen jeden ze zdrojů.
GC uvolní i jiné zdroje - nebude to však okamžitě, což může být problém. Naopak, když se smart pointery uděláte cyklus, tak se zdroj nemusí uvolnit nikdy, což je ještě horší.
Linked list pomocí smart pointrů je fakt blbý nápad
Takže doporučujete ruční správu paměti?
Chtěl jsem jen upozornit na to, že ten benchmark neměřil pomalost C++ ale špatně použitých smart pointerů a datové struktury která se do C++ moc nehodí.
Cílem nebylo měřit rychlost nějaké implementace C++, ale rychlost naivního počítání referencí.
-
Tak co se memory managementu týče, C++ je jednoznačně rychlejší, na tom se snad shodneme. Jestli to má být náročná aplikace, tak bych C++/C určitě zvážil. Celkově si prostě kvůli výkonu radši vyberu C/C++ aplikaci než něco v Javě. Ale je to něco za něco... když se vám runtime stará o paměť, tak se samozřejmě vyvíjí snáz. Jestli to je něco co se bude neustále vyvíjet a kde je rychlost vývoje důležitá, Javu bych zvážil.
No já jsem slyšel, že GC v HotSpot je vůbec nejrychlejší memory management (tzn. by měl být i efektivnější než implementace malloc). Těžko říct, jak to objektivně nějak srovnat. Asi celkový čas strávený alokacemi/dealokacemi u nějakého většího programu je nejmenší. Padlo to někde v přednášce "Understanding Java Garbage Collection", co byla na Java One 2014 konferenci.
V GC je alokace O(1), malloc (nebo new) občas může trvat déle. U většiny aplikací je to stejně jedno.
-
V tom, ze Python ma GIL a zjevne se s tim nic moc delat nebude. Coz je v 21. stoleti ponekud trapne :)
Proc by to bylo trapne? Realita je, ze nikdo nevi co s tim. A pokud vim, tak GIL je problem pouze u CPU-bound aplikaci, ktere jsou napsane primo v Pythonu. GIL neznamena, ze Python nemuze provadet veci konkurentne (jako treba GUI vlakna), ani to neznamena, ze ho externi knihovna nemuze obejit. Konecne, kdyby se GIL odstranil, znamenalo by to snizit vykon jednoduchych (jednovlaknovych) skriptu, coz je asi tak 90% vyuziti Pythonu. Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?
-
Mé zkušenosti z mnoha projektů: Záleží na použití: pokud děláš multiplatformní GUI, pak C++ a Qt; GUI pro Linux, pak C++ a GTK nebo KDE libs; GUI pro Windows, pak C# a .NET. Pro embeded GUI je vhodný specializovaný framework a C++ - ale s úspěchem lze použít i C# a Javu (záleží na OS a procesoru). Pro servery - opět záleží, co děláš - pokud je potřeba komunikace s HW nebo nízkoúrovňový přístup, tak C/C++. Pro práci s DB potom Java nebo C#. Mně se upřímně Java moc neosvědčila, takže doporučuji C#. Javu zde sice mnoho lidí doporučovalo, ale upřímně - neznám žádnou rychlou velkou aplikaci v Javě - zejména, pokud jde o GUI. Navíc k Javě se v mém okolí většinou uchýlí lidé, co moc programovat neumí (nic proti Javě samotné) a ten kód podle toho pak vypadá. V C++/C# týmech najdu většinou kvalitnější programátory - čímž neříkám, že v Javě není mnoho opravdových borců, co píšou skvělý SW! Naopak v C++ týmech zas najdu hodně exotů.
-
Souhlasím, že v GUI aplikacích to využiju parádně, moje vyjádřená pochybnost (Python jako lepidlo) se však týkala jen grafické vrstvy GUI aplikace. Proto nekliknu a nepřepočítává... po kliknutí se spustí nativní aplikace, jejíž procesorový čas řídí OS a ne Python. Zatímco já si povídám skrz guiksicht s Pythonem, nativní aplikace vyřeší multiprocesorově problém a výsledek přichystá Pythonu na podnose, kde si ho příležitostně vyzvedne a použije v komunikaci se mnou.
Spouštět pro každou GUI událost (to nemusí být jenom kliknutí, ale třeba i najetí myší do nějaké oblasti) by bylo tragicky neefektivní a nedělá se to tak. Když už se chce tahle masařka Pythonu obejít, dělá se to tak, že se GIL releasne (to má nějaké předpoklady) a provede se nativní kód v novém vláknu. Nebo se v novém vláknu spustí celý nový interpret. Každopádně to znamená, že v tom novém vláknu nemůžeš volně manipulovat s datovými strukturami, se kterými jinak v Pythonu pracuješ.
Pokud by se to dělalo tak, jak píšeš, tak by tam ten Python byl jenom na ozdobu, protože drtivá většina zpracování by jela v tom jiném jazyce.
Proc by to bylo trapne? Realita je, ze nikdo nevi co s tim.
No právě. A to je v 21. století poněkud trapné, že se v jazyce nedá rozumně psát konkurentní aplikace...
A pokud vim, tak GIL je problem pouze u CPU-bound aplikaci, ktere jsou napsane primo v Pythonu. GIL neznamena, ze Python nemuze provadet veci konkurentne (jako treba GUI vlakna), ani to neznamena, ze ho externi knihovna nemuze obejit.
Jasně. Ale je to prostě opruz, musí se to řešit, vznikají chyby, kód je složitější... Je to prostě podobná berlička jako když do by-design jednovláknového JavaScriptu namatleš tisíce callbacků (ideálně vnořených tak do 5. až 75. úrovně) a pak ti z toho jde hlava kolem...
Konecne, kdyby se GIL odstranil, znamenalo by to snizit vykon jednoduchych (jednovlaknovych) skriptu, coz je asi tak 90% vyuziti Pythonu.
Nemám proti Pythonu vůbec nic, je to podle mě nadstandardně pěkný jazyk a na skripty ho používám moc rád, ale na větší věci (a to je naše téma) se podle mě moc nehodí, hlavně kvůli GILu a ani volitelné podpoře typů. Že je dneska móda cpát Python všude a ohýbat ho na všechno, je jiná věc.
Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?
Na tom něco je. Potom ale jestli je semafor dobře navržený na to, aby řídil dopravu, nemusí být úplně dobrý nápad ho používat jako soustruh. Od toho tu je prostě soustruh, který se na to hodí líp :)
-
Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?
Nemusí být úplně jako JVM. Například nemusí mít jednu velkou haldu, jenž sdílí všechna vlákna, může mít i více hald a jen některé z nich mohou být sdílené více vlákny.
-
No právě. A to je v 21. století poněkud trapné, že se v jazyce nedá rozumně psát konkurentní aplikace...
Tohle musím upřesnit: ne v jazyce, ale v jeho konkrétní implementaci. IronPython ani JPython afaik GIL nemají.
-
Javu zde sice mnoho lidí doporučovalo, ale upřímně - neznám žádnou rychlou velkou aplikaci v Javě - zejména, pokud jde o GUI.
ebay amazon twitter linkedin foursquare (ok nieco z toho je scala)
gui java je zriedkava: prakticky je mozne vidiet len netbeans, eclipse a intellj ideu. alebo nieco na rich client platforme. alebo gui pre predaj listkov na vlaky na slovensku.
-
Spouštět pro každou GUI událost (to nemusí být jenom kliknutí, ale třeba i
najetí myší do nějaké oblasti) by bylo tragicky neefektivní... že v tom novém vláknu nemůžeš volně manipulovat s datovými strukturami, se kterými jinak v Pythonu pracuješ.
Pro každou událost ne, na spoustu z nich přeci stačí ten Pythonskej 'multithreading', s nejvyšší jemností jedné python-instrukce. Problémy se přeci dají plus-mínus rozdělit do dvou disjunktních množin:
- na ty, které trvají delší dobu a na tuto delší dobu nebudou potřebovat další manipulaci s
datovými strukturami
- na ty druhé ;-)
Asi mám díky své nezkušenosti špatnou představu o potřebách pro skutečně velké projekty, protože jsem zatím nevylezl ze svého písečku, na kterém mnou zmíněná představa dokonale funguje O:-) Pro skutečně hodně paralelizované věci má zřejmě Java+Clojure trumf v rukávu ... diverzita rulez!, díky za trpělivost :-)
-
Mé zkušenosti z mnoha projektů: Záleží na použití: pokud děláš multiplatformní GUI, pak C++ a Qt; GUI pro Linux, pak C++ a GTK nebo KDE libs; GUI pro Windows, pak C# a .NET. Pro embeded GUI je vhodný specializovaný framework a C++ - ale s úspěchem lze použít i C# a Javu (záleží na OS a procesoru). Pro servery - opět záleží, co děláš - pokud je potřeba komunikace s HW nebo nízkoúrovňový přístup, tak C/C++. Pro práci s DB potom Java nebo C#. Mně se upřímně Java moc neosvědčila, takže doporučuji C#. Javu zde sice mnoho lidí doporučovalo, ale upřímně - neznám žádnou rychlou velkou aplikaci v Javě - zejména, pokud jde o GUI. Navíc k Javě se v mém okolí většinou uchýlí lidé, co moc programovat neumí (nic proti Javě samotné) a ten kód podle toho pak vypadá. V C++/C# týmech najdu většinou kvalitnější programátory - čímž neříkám, že v Javě není mnoho opravdových borců, co píšou skvělý SW! Naopak v C++ týmech zas najdu hodně exotů.
GUI, GUI, GUI… Rozhodovat se o jazyku, v němž mám napsat nějaký projekt, na základě předpokládaného GUI, tak tomu říkám úchylárna pro 21. století. Říkám to pořád – někteří lidé by se opravdu měli zabývat něčím jiným než vývojem programů.
-
Ja bych rekl:
pokud mas neomezene prostredku(no, proste hodne casu/programatoru/problem je paralelizovatelny) a potrebujes brutalni vykon, popripade potrbujes mit garantovane doby reakci, tak C++. Pokud ten vykon nepotrebujes a potrebujes to mit hotovo rychleji/levneji, ci potrebujes aby to mohl maintenovat lecjaky lempl, tak Java.
Pokud to neni vubec narocne na vykon a chces usetrit naklady na vyvoj jeste vic, a neni to prilis rozsahly sytem(kde se uz sakra projevi typovany jazyk), tak Python.
-
Co je velkej projekt. Předně bych velký projekt rozdělil na malé projekty. Já mám (pod správou) třeba hodně věcí v C++, zpravidla servery. Aplikace jsou v Javě, v Objective C (hádejte které), ale na serverech se používá i PHP. Na webovkách javascript. Jedna komponenta je napsaná v C#
-
Chces vydelat prachy? Java
Chces si honit brko ve sklepe pred ostatnima zombikama? Instrukce
-
Chces vydelat prachy? Java
Chces si honit brko ve sklepe pred ostatnima zombikama? Instrukce
Umět assembler je dobré aspoň pasivně. Onehdy jsem řešil, jak tento kód
flag = (b==true?1:0)
může způsobit, že v proměnné flag bude číslo 52 (GCC 4.8)
Až průzkumem přeloženého kódu na úrovni -O3 jsem zjistil, v čem je zakopanej pes.
-
Ake datove typy su ten flag a b? A teda v com bol problem?
-
Chces vydelat prachy? Java
Chces si honit brko ve sklepe pred ostatnima zombikama? Instrukce
To je samozrejme pi... jak mraky.Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
Java ma svoje vyhody v rychlosti vyvoje a nevyhody ve vykonu aplikace. Vetsinou se o vykon aplikace(pripadne setreni prostredku) nejedna, proto nema smysl se trapit s c++.
-
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
minecraft trololo
inak mate pravdu javu zavriete na x serverov a nechate ju riesit linkedin, na hry hru zvolite c++
-
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
minecraft trololo
inak mate pravdu javu zavriete na x serverov a nechate ju riesit linkedin, na hry hru zvolite c++
Len PC verzia Minecraft-u je pisana v Jave, vsetky ostatne (PS3, PS4, X360, XONE, PSVita, Pocket Edition) su napisane v C++.
-
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
Prosim o definici "poradne hry". Minecraft je (alespon podle wiki (https://en.wikipedia.org/wiki/List_of_best-selling_PC_games)) nejvice prodavanou PC hrou. Ma po dekompilaci ~180k loc (udaj je logicky pouze kod, bez komentaru), Quake 3 (vcetne enginu) s komentari mel ~300k loc. Jestli ani tohle neni poradna hra, tak uz nevim co je.
Co jsem tak sledoval, hodne indie her je nyni psanych v C# ci Jave (i 3d her, ne uplne jednoduchych). A enginy, ktere tvorily prave vetsinu kodu, se uz prestavaji psat na kolene a radeji se pouzivaji hotove vytunene.
PS: Je tady jeste problem srovnavani loc Javy a C++.
-
Ake datove typy su ten flag a b? A teda v com bol problem?
b je bool, flag byl int
problem byl v tom, že překladač předpokládá, že boolean je reprezentován jako true=1, false=0. Výše uvedený zápis se tedy v optimalizované verzi na úrovni -O3 vůbec nepřeložil, v kódu byl na tom místě obyčejný mov proměnné do proměnné. Což je v pořádku, pokud je opravdu dodrženo výše zmíněné kódování. Jenže proměnná b neobsahovala 1 jako true, ale číslo 52. Při testu if (b) to pořád funguje správně (testuje se na nulu). Ale operátor ?: už dopadl špatně díky jeho nepřeložení... Chybou bylo, že proměnná b nebyla inicializovaná
-
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
Prosim o definici "poradne hry". Minecraft je (alespon podle wiki (https://en.wikipedia.org/wiki/List_of_best-selling_PC_games)) nejvice prodavanou PC hrou. Ma po dekompilaci ~180k loc (udaj je logicky pouze kod, bez komentaru), Quake 3 (vcetne enginu) s komentari mel ~300k loc. Jestli ani tohle neni poradna hra, tak uz nevim co je.
Co jsem tak sledoval, hodne indie her je nyni psanych v C# ci Jave (i 3d her, ne uplne jednoduchych). A enginy, ktere tvorily prave vetsinu kodu, se uz prestavaji psat na kolene a radeji se pouzivaji hotove vytunene.
PS: Je tady jeste problem srovnavani loc Javy a C++.
Jo, Minecraft je napsaný v Javě a taky to podle toho vypadá. A prodávanost opravdu není dobrým indikátorem výběru vhodného jazyka. To by jste rovnou mohl tvrdit že Windows je skvěle navržený operační systém...
-
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
Prosim o definici "poradne hry". ....
Poradne hry myslim Ackove hry. To ze je jedna uspesna hra, minecraft, psana v Jave jeste neznamena, ze v tom muzes udelat 99% i vsech ostatnich Ackovych her.
Uznavam, ze u her, kde technicke zpracovani jde stranou mozna se Java pouzit da. Tam kde je treba ale z HW vymacknout maximum, tak tam fakt ne.
-
Chybou bylo, že proměnná b nebyla inicializovaná
A to mi neříkej, že tě překladač nevaroval, že testuješ hodnotu neinicializované proměnné.
-
Jo, Minecraft je napsaný v Javě a taky to podle toho vypadá.
Jestli narazite na vykonost, tak vanilla Minecraft je hratelny na beznem kancelarskem orezavatku. Nebo podle ceho "to vypada"? Pokud se vam nelibi estetika, tak to je ciste subjektivni a IMO bez toho unikatniho vzhledu by MC nikdy neprorazil.
A prodávanost opravdu není dobrým indikátorem výběru vhodného jazyka. To by jste rovnou mohl tvrdit že Windows je skvěle navržený operační systém...
A co je tedy "poradna" hra? Uspesna, dobre hodnocena, prodavana, ziskova, s hodne radky kodu, originalni v nejakem aspektu, s odehranymi miliardami hodin, nebo s vyhozenymi miliony v grafice jako vetstina nynejsich 3A? Jen jsem reagoval na to, ze na "poradnou" hru si nevyberu Javu. Pritom ale tu nepopiratelne je Minecraft... (A dokonce, jak tu nekdo poznamenal, jeho porty nejedou nad JVM.)
Mel jsem pocit, ze zrovna Winy jsou v C++, takze ani volba jazyka je nezachranila ;D.
(Po dopsani textu dosla dalsi odpoved, rovnou tedy zareaguji.)
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
Prosim o definici "poradne hry". ....
Poradne hry myslim Ackove hry. To ze je jedna uspesna hra, minecraft, psana v Jave jeste neznamena, ze v tom muzes udelat 99% i vsech ostatnich Ackovych her.
Uznavam, ze u her, kde technicke zpracovani jde stranou mozna se Java pouzit da. Tam kde je treba ale z HW vymacknout maximum, tak tam fakt ne.
Jak jsem psal vyse, myslim ze ten trend uvidime vice a vice. Tezkou praci odedrou enginy napsane v C++, ale na herni logiku (tj. to, v cem jsou hry psane) bude "stacit" i Java/C#. Uz nyni jsou cim dal vetsi casti her psany v nejakem skriptovacim jazyce ala Lua nebo JS. Navic i s tim vykonem je to znacne diskutabilni, videl jsem hodne benchmarku, kde Java (po nekolika stovkach iteraci) porazela C++.
-
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
Prosim o definici "poradne hry". ....
Poradne hry myslim Ackove hry. To ze je jedna uspesna hra, minecraft, psana v Jave jeste neznamena, ze v tom muzes udelat 99% i vsech ostatnich Ackovych her.
Uznavam, ze u her, kde technicke zpracovani jde stranou mozna se Java pouzit da. Tam kde je treba ale z HW vymacknout maximum, tak tam fakt ne.
zde se to probiralo, takze se tu nebudu rozepisovat
http://forum.dlang.org/thread/xozchleoiyxbsalbevlg@forum.dlang.org
-
Jo, Minecraft je napsaný v Javě a taky to podle toho vypadá.
Jestli narazite na vykonost, tak vanilla Minecraft je hratelny na beznem kancelarskem orezavatku. Nebo podle ceho "to vypada"? Pokud se vam nelibi estetika, tak to je ciste subjektivni a IMO bez toho unikatniho vzhledu by MC nikdy neprorazil.
A prodávanost opravdu není dobrým indikátorem výběru vhodného jazyka. To by jste rovnou mohl tvrdit že Windows je skvěle navržený operační systém...
A co je tedy "poradna" hra? Uspesna, dobre hodnocena, prodavana, ziskova, s hodne radky kodu, originalni v nejakem aspektu, s odehranymi miliardami hodin, nebo s vyhozenymi miliony v grafice jako vetstina nynejsich 3A? Jen jsem reagoval na to, ze na "poradnou" hru si nevyberu Javu. Pritom ale tu nepopiratelne je Minecraft... (A dokonce, jak tu nekdo poznamenal, jeho porty nejedou nad JVM.)
Mel jsem pocit, ze zrovna Winy jsou v C++, takze ani volba jazyka je nezachranila ;D.
(Po dopsani textu dosla dalsi odpoved, rovnou tedy zareaguji.)
Nevsim jsem si, ze by se poradne hry delaly treba v Jave.
Prosim o definici "poradne hry". ....
Poradne hry myslim Ackove hry. To ze je jedna uspesna hra, minecraft, psana v Jave jeste neznamena, ze v tom muzes udelat 99% i vsech ostatnich Ackovych her.
Uznavam, ze u her, kde technicke zpracovani jde stranou mozna se Java pouzit da. Tam kde je treba ale z HW vymacknout maximum, tak tam fakt ne.
Jak jsem psal vyse, myslim ze ten trend uvidime vice a vice. Tezkou praci odedrou enginy napsane v C++, ale na herni logiku (tj. to, v cem jsou hry psane) bude "stacit" i Java/C#. Uz nyni jsou cim dal vetsi casti her psany v nejakem skriptovacim jazyce ala Lua nebo JS. Navic i s tim vykonem je to znacne diskutabilni, videl jsem hodne benchmarku, kde Java (po nekolika stovkach iteraci) porazela C++.
Mno, engine v c++, zbytek ve skriptovacich jazycich. Neni duvod tam mit tu Javu.
Tyhlety testy jsou vetsinou uplne k hovnu, protoze autor vetsinou jednu nebo druhou stranu posere(s prominutim).
Aby bylo jasno, ja proti Jave nic nemam, z casti me zivi(stejne jako C++) a proste vidim, ze v nekterych pripadech vykonove vubec nestiha. Z druhe strany vyvoj je v ni mnohem rychlejsi. V C++ je take jednoduche napsat dementne neefektivni kod, ale pokud se clovek dostatecne zamysli, opravdu se da optimalizovat vice - za cenu hory casu straveneho pri kodeni.
-
Myslím to tak, že na to jak Minecraft vypadá, je na HW poměrně náročný. Proč myslíte, že všechny nové verze jsou v C++?
-
Myslím to tak, že na to jak Minecraft vypadá, je na HW poměrně náročný. Proč myslíte, že všechny nové verze jsou v C++?
Nevim, mozna protoze na cilove platforme neni Java (nevim, jen placam)? Take oznaceni "nove verze" je takove divne, jsou to porty, nejsou to novejsi = lepsi verze hry. Hlavni "verze" je na PC a ta je stale v Jave.
Zajimalo by me, s cim srovnavate. Ono totiz pracovat s voxelovym svetem neni zadna sranda. Par voxelovych veci v C++ jsem zkousel (myslim ze cubeworld a trove) a vetsinou jely jeste hur nez Minecraft (navic s mnohem horsi dohlednosti i grafikou). Dokud jsem si nezkusil napsat rendrovani voxeloveho sveta, tak jsem myslel, jak je Minecraft spatne napsany. Az po teto zkusenosti jsem zjistil, jak je Minecraft (relativne) dobre napsany, na vine je totiz nepodpora jak HW tak SW pro operace s voxely (kdyz jsem to zkousel, tak nebyl zadny engine/knihovna pro Javu podporujici voxely - svet, chunky, meshing, svetlo atd.).
-
Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?
Nemusí být úplně jako JVM. Například nemusí mít jednu velkou haldu, jenž sdílí všechna vlákna, může mít i více hald a jen některé z nich mohou být sdílené více vlákny.
No v JVM se taky napred alokuje na casti haldy lokalni pro jednotliva vlakna, je to potom mega rychle (jen posun ukazatele) a teprve, kdyz objekt prezije nejakou dobu, tak se dostane do jine oblasti haldy.
-
Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?
Nemusí být úplně jako JVM. Například nemusí mít jednu velkou haldu, jenž sdílí všechna vlákna, může mít i více hald a jen některé z nich mohou být sdílené více vlákny.
No v JVM se taky napred alokuje na casti haldy lokalni pro jednotliva vlakna, je to potom mega rychle (jen posun ukazatele) a teprve, kdyz objekt prezije nejakou dobu, tak se dostane do jine oblasti haldy.
Máte na mysli standardní vícegenerační kolektor?
Já měl na mysli to, že objekty zůstávají na lokální haldě, dokud k nim nepřistoupí jiné vlákno. Výhodou je, že s těmito objekty můžete pracovat jako v programech s GIL, čímž jsem reagoval na poznámku "Konecne, kdyby se GIL odstranil, znamenalo by to snizit vykon jednoduchych (jednovlaknovych) skriptu" od JS.
-
Myslím to tak, že na to jak Minecraft vypadá, je na HW poměrně náročný. Proč myslíte, že všechny nové verze jsou v C++?
Nevim, mozna protoze na cilove platforme neni Java (nevim, jen placam)? Take oznaceni "nove verze" je takove divne, jsou to porty, nejsou to novejsi = lepsi verze hry. Hlavni "verze" je na PC a ta je stale v Jave.
Zajimalo by me, s cim srovnavate. Ono totiz pracovat s voxelovym svetem neni zadna sranda. Par voxelovych veci v C++ jsem zkousel (myslim ze cubeworld a trove) a vetsinou jely jeste hur nez Minecraft (navic s mnohem horsi dohlednosti i grafikou). Dokud jsem si nezkusil napsat rendrovani voxeloveho sveta, tak jsem myslel, jak je Minecraft spatne napsany. Az po teto zkusenosti jsem zjistil, jak je Minecraft (relativne) dobre napsany, na vine je totiz nepodpora jak HW tak SW pro operace s voxely (kdyz jsem to zkousel, tak nebyl zadny engine/knihovna pro Javu podporujici voxely - svet, chunky, meshing, svetlo atd.).
No zrovna Minetest mi běžel na Mobilním dvoujádru znatelně líp... a nejsou náročné operace s voxely jenom dalším důvodem pro C++?
-
Myslím to tak, že na to jak Minecraft vypadá, je na HW poměrně náročný. Proč myslíte, že všechny nové verze jsou v C++?
Nevim, mozna protoze na cilove platforme neni Java (nevim, jen placam)? Take oznaceni "nove verze" je takove divne, jsou to porty, nejsou to novejsi = lepsi verze hry. Hlavni "verze" je na PC a ta je stale v Jave.
Zajimalo by me, s cim srovnavate. Ono totiz pracovat s voxelovym svetem neni zadna sranda. Par voxelovych veci v C++ jsem zkousel (myslim ze cubeworld a trove) a vetsinou jely jeste hur nez Minecraft (navic s mnohem horsi dohlednosti i grafikou). Dokud jsem si nezkusil napsat rendrovani voxeloveho sveta, tak jsem myslel, jak je Minecraft spatne napsany. Az po teto zkusenosti jsem zjistil, jak je Minecraft (relativne) dobre napsany, na vine je totiz nepodpora jak HW tak SW pro operace s voxely (kdyz jsem to zkousel, tak nebyl zadny engine/knihovna pro Javu podporujici voxely - svet, chunky, meshing, svetlo atd.).
No zrovna Minetest mi běžel na Mobilním dvoujádru znatelně líp... a nejsou náročné operace s voxely jenom dalším důvodem pro C++?
Nedalo mi to a srovnal jsem to na svem prehistorickem ctyrjadru v opengl (berte jen orientacne, muselo by se provest mnohem vice testu; oboje byla nova mapa a pockani ~minuty dokud se nestabilizuje fps, pri mereni jsem nechodil, pouze se rozhlizel):
Minetest 0.4.12 64b msvc: 30-60fps (bez mlhy, velmi mala dohlednost 5 [netusim jak se pocita])
Minecraft 1.8.8 (java 7 64b): 85-120fps (s mlhou, vbo, fancy grafika, dohlednost 10 chunku; s vecmi jako optifine to muze byt jeste lepsi [mod])
Mozna polamany build Minetestu? Zajimave, ze ne uplne optimalizovany MC z toho vychazi podstatne lepe nez MT v C++ ???. Po pravde jsem ocekaval spis tesnou prohru Minecraftu. Nebo ze by ten JIT delal tolik?
-
Tak to na tom asi hoši zapracovali... (já to srovnával s tím, co jsem kdysi zkoušel, takže okolo konce beta verze... ale i tam sem možná mimo, protože žádnej test sem nedělal). Je fakt, že ten rozdíl ve "výkonu" jazyků neni až zas tak zásadní. GCC je sice lepší než MSVC, ale FPS by to asi nezdvojnásobilo. Ono je to hodně taky o tom jaký druh lidí ten jazyk používá... jak řekl Linus: i jen odrazení C++ "programátorů" by bylo dostatečným důvodem pro používání C místo C++.
-
Chybou bylo, že proměnná b nebyla inicializovaná
A to mi neříkej, že tě překladač nevaroval, že testuješ hodnotu neinicializované proměnné.
No... nevaroval. Ono to bylo složitější. Překladač neumí vždy zjistit všechny okolnosti, někdy stačí, když ta proměnná je předávána do funkce referenci a v tu chvíli se tohle varovaní neobjeví. Nechci zabíhat do detailů
-
Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?
Nemusí být úplně jako JVM. Například nemusí mít jednu velkou haldu, jenž sdílí všechna vlákna, může mít i více hald a jen některé z nich mohou být sdílené více vlákny.
No v JVM se taky napred alokuje na casti haldy lokalni pro jednotliva vlakna, je to potom mega rychle (jen posun ukazatele) a teprve, kdyz objekt prezije nejakou dobu, tak se dostane do jine oblasti haldy.
Máte na mysli standardní vícegenerační kolektor?
Já měl na mysli to, že objekty zůstávají na lokální haldě, dokud k nim nepřistoupí jiné vlákno. Výhodou je, že s těmito objekty můžete pracovat jako v programech s GIL, čímž jsem reagoval na poznámku "Konecne, kdyby se GIL odstranil, znamenalo by to snizit vykon jednoduchych (jednovlaknovych) skriptu" od JS.
Ano, vícegenerační kolektor, pouze doplněný o TLAB (Thread Local Allocation Buffer). Idea je jednoduchá - po proběhnutí GC nad edenem je pro každé vlákno zajištěno, že má k dispozici zcela prázdnou oblast (o nějaké velikosti) pro alokaci objektů. Alokace je potom triviální - jen se posune ukazatel na první volný bajt (no spíše 32bitové slovo) o velikost alokovaného objektu + případná kontrola na překročení velikosti TLAB. Žádné zjišťování volného místa jako malloc(), žádný zámek, jako při přístupu ke globální haldě, velikost TLAB se počítá a jde nějak nastavit (to z hlavy už neřeknu, musel bych se podívat do zdrojáků OpenJDK, ale jde to poštelovat). Vlastně to není žádná rocket science. S tou lokální haldou je to zajímavý nápad, bylo by fajn vidět, jak to bude vypadat v reálu (asi by ty oblatsi musely být "nafukovací", ale to neva).
Trošku je to popsáno zde: https://blogs.oracle.com/jonthecollector/entry/the_real_thing
-
Žádné zjišťování volného místa jako malloc(), žádný zámek, jako při přístupu ke globální haldě
Jen řeknu, že v trochu pokročilých c++ programech se malloc / global new používá jen opravdu pro objekty s dlouhou životnosti. Tam kde je trochu známý vzorec alokací, tam se používá něco rychlejšího.
Ve svých programech mám poolalloc - lockless rychlá alokace objektů s předem daného poolu. Nebo používám známý alokátor malých objektů od Andrei Alexandrescu. Všechny tyhle custom alokátory se často s výhodou realizují per thread bez zámků a v přiděleném bloku paměti a do globální haldy se chodí minimálně. A to jsem při nedávných testech zjišťoval, že optimalizace alokací probíhá i na úrovni OS a překladačů v C++. Třeba v posledních verzích MSVC je celkem obtížné napsat alokátor, který by konkuroval jejich implementaci new/malloc (testováno v praxi) - s výjimkou těch pro specifické použití.
Tak jako probíhá vývoj strategií GC, probíhá vývoj i tam kde se GC nepoužívá.
-
Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?
Nemusí být úplně jako JVM. Například nemusí mít jednu velkou haldu, jenž sdílí všechna vlákna, může mít i více hald a jen některé z nich mohou být sdílené více vlákny.
No v JVM se taky napred alokuje na casti haldy lokalni pro jednotliva vlakna, je to potom mega rychle (jen posun ukazatele) a teprve, kdyz objekt prezije nejakou dobu, tak se dostane do jine oblasti haldy.
Máte na mysli standardní vícegenerační kolektor?
Já měl na mysli to, že objekty zůstávají na lokální haldě, dokud k nim nepřistoupí jiné vlákno. Výhodou je, že s těmito objekty můžete pracovat jako v programech s GIL, čímž jsem reagoval na poznámku "Konecne, kdyby se GIL odstranil, znamenalo by to snizit vykon jednoduchych (jednovlaknovych) skriptu" od JS.
Ano, vícegenerační kolektor, pouze doplněný o TLAB (Thread Local Allocation Buffer). Idea je jednoduchá - po proběhnutí GC nad edenem je pro každé vlákno zajištěno, že má k dispozici zcela prázdnou oblast (o nějaké velikosti) pro alokaci objektů. Alokace je potom triviální - jen se posune ukazatel na první volný bajt (no spíše 32bitové slovo) o velikost alokovaného objektu + případná kontrola na překročení velikosti TLAB. Žádné zjišťování volného místa jako malloc(), žádný zámek, jako při přístupu ke globální haldě, velikost TLAB se počítá a jde nějak nastavit (to z hlavy už neřeknu, musel bych se podívat do zdrojáků OpenJDK, ale jde to poštelovat). Vlastně to není žádná rocket science.
Trošku je to popsáno zde: https://blogs.oracle.com/jonthecollector/entry/the_real_thing
Díky za podrobné info.
S tou lokální haldou je to zajímavý nápad, bylo by fajn vidět, jak to bude vypadat v reálu (asi by ty oblatsi musely být "nafukovací", ale to neva).
O uvedení něčeho podobného do praxe se snaží Multicore OCaml (https://ocaml.org/meetings/ocaml/2014/ocaml2014_1.pdf). Nicméně OCaml nemá naivní počítání referencí - bylo by proto zajímavé vidět, jak by si vedl Python.
-
Tam kde je trochu známý vzorec alokací, tam se používá něco rychlejšího.
To se používá i v C#, když máte vzorec alokací, na nějž není GC optimalizován - například, když máte hodně (v řádu miliard) malých a dlouhožijících objektů.
-
Myslím to tak, že na to jak Minecraft vypadá, je na HW poměrně náročný. Proč myslíte, že všechny nové verze jsou v C++?
Viz. muj odkaz vyse. Ono to ze to vypada jako hodne stara hra jeste nezmamena ze to ve vysledku neni propracovane 3D :).
http://forum.dlang.org/post/burwguoxiqrlfaogiezo@forum.dlang.org