Je C++ dobrá volba na větší projekt?

[noef]

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?

[Reklama]

[_________]

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

[Ondřej Novák]

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ů

[Pavel Tisnovsky]

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

[Ondřej Novák]

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

[Reklama]

[Radek Miček]

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. Nicméně OCaml nemá naivní počítání referencí - bylo by proto zajímavé vidět, jak by si vedl Python.

[Radek Miček]

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

[Daniel Kozak]

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