Prepis utility MinetestMapper do C++ a benchmarky C++ / Py

18.9.2012 22:50 | Přečteno: 1321× | Programovanie | poslední úprava: 18.9.2012 22:51

V lete počas najvyšších teplôt som narazil na malý problém s mojim súkromným minetest serverom. Používal som nástroj minetestmapper.py pre generovanie obrázku z aktuálnej mapy. Vygenerovanie mapy s týmto nástrojom trvalo približne hodinu, čo spôsobovalo prehrievanie CPU. Preto (a samozrejme aj zo zvedavosti) som sa rozhodol prepísať tento nástroj do C++. Dnes som sa tento program pokúsil použiť ako malý nesytetický benchmark kompilátorov. Okrem neho v blogu nájdete zopár informácií o fungovaní hry minetest.

O hre minetest

Minetest je slobodný klon hry minecraft napísaný v C++. Zdrojové kódy hry sú dostupné na Github-e. Aplikácia používa engine irrlicht. Skriptovanie je možné v jazyku LUA, možnosti sú však zatiaľ dosť obmedzené kvôli chýbajúcemu API. Napriek spomínaným obmedzeniam v tejto hre vznikajú podobné „divočiny“ ako v pôvodnom minecrafte. Malú ukážku je možné nájsť v minetest fóre.

Mapa

Celá hra minetest je podobne ako minecraft založená na voxeloch (obdoba pixelov v 3D). Mapa sa skladá z kociek pevnej veľkosti, ktoré môžu byť rozmiestnené len na presných pozíciách v štvorcovej mriežke.

Svet môže mať rozmery 4096 blokov vo všetkých 3 rozmeroch. Každý blok sa skladá z 16 ∗ 16 ∗ 16 voxelov. Svet môže mať teda rozmery 65536 ∗ 65536 ∗ 65536 (281 474 976 710 656) voxelov. Pri takomto množstve voxelov samozrejme nie je možné rozumne pracovať s celou mapou a tak mapa obsahuje len už vygenerované v minulosti použité bloky.

Ukladanie mapy

V aktuálnej verzii minetestu sa mapa ukladá do SQLite databázy (áno čítate správne). Databáza obsahuje jedinú tabuľku s dvomi stĺpcami - pos (long) a data (blob). V stĺpci pos sú zakódované všetky 3 súradnice. Súradnice sú 12-bitové signed čísla, spolu zaberajú 36 bitov, čo sa bez problémov zmestí do 64-bitového typu long.

Štruktúra dát

Prvých 8 bitov každého bloku obsahuje číslo verzie. Pri ďalšom popise budem predpokladať, že obsahuje najnovšiu verziu. Po pár-bytovom offsete nasledujú dva bloky dát komprimované zlib-om. Pre generovanie mapy je pre nás podstatný len prvý obsahujúci 16 ∗ 16 ∗ 16 16-bitových čísel (až sa vám to zdá šialene nadýchnite sa na chvíľu, lebo to čo príde rozhodne nebude pekné), ktoré odkazujú do tabuľky materiálov bloku (k tej sa dostanem v nasledujúcom odseku).

Po prečítaní (a zahodení) metadát sa dostaneme k tabuľke materiálov. Každý blok má svoju vlastnú tabuľku materiálov, čo je zoznam dvojíc id materiálu - názov materiálu. ID je 16-bitové číslo a názov je reťazec maximálnej dĺžky 65536 znakov. Základné materiály majú anglické názvy ako „air“, „water“, „sand“ … Materiály definované v skriptoch majú väčšinou tvar prefix_skriptu:názov.

Prevod materiálov na farbu

Materiály sa prevádzajú na farbu podľa konfiguračného súboru colors.txt. Prvá položka riadku je názov materiálu, za ktorým nasledujú hodnoty červenej, zelenej a modrej farby. Celý prevod materiálu voxelu na farbu vyzerá teda nasledovne:

• načítanie 16-bitového indexu materiálu z bloku
• vyhľadanie názvu materiálu podľa indexu (1. prístup do asociatívneho poľa)
• nájdenie farby podľa názvu materiálu (2. prístup do asociatívneho poľa)

Generovanie obrázku mapy

Pri generovaní obrazu sú voxely mapované presne na pixely. Pre každý pixel mapy je potrebné najskôr nájsť neprehľadný materiál na najvyššej pozícii na y-ovej osi. Podľa materiálu sa na danej x a z pozícii vykreslí pixel.

Počas vykresľovania obrazu sa pre každý pixel zaznamenáva aj y súradnica. Podľa nej sa následne vykresľuje tieňovanie terénu.

Pôvodný minetest mapper

Pôvodný generátor mapy je napísaný v pythone. Najviac procesorového času je tu spotrebovaného na jednoduché operácie ako bitové posuny, logický OR, posuny v streame … Tie sú v C++ vykonávané väčšinou 1 taktom CPU. Python však interpretuje bytecode a každá jednoduchá operácia preto trvá niekoľko taktov CPU.

Nasledujúce časy sú namerané pre moju malú testovaciu mapku (752px ∗ 512px). Testovací stroj ma CPU Intel Core2 Duo T5250 (1.5GHz):

Interpret	Čas
Python 2.7	120,04s
PyPy 1.9 s JIT	87s

Benchmarkujeme minetest mapper v C++

Môj pomerne chaotický prepis Python verzie do C++ je možné nájsť na Github-e. Kód nie je úplne ekvivalentný, ale výstup je takmer na pixel rovnaký (python verzia má nejaký bug, ktorý sa mi nepodarilo opraviť).

Pri benchmarkovaní bol každý test spustený 50x. Meraný bol čas od spustenia po ukončenie aplikácie (tj. nie len procesorový čas, ale aj I/O a čas strávený systémovými volaniami). Pri optimalizácii O1 a vyššie bol zapnutý flag -march core2. Súhrnné výsledky sú v nasledujúcej tabuľke.

Kompilátor	Priemer	Interval spoľahlivosti (90%)	Minimálny čas	Maximálny čas
gcc-4.5 (O0)	2.515	2.486 - 2.544	2.489	2.576
gcc-4.6 (O0)	2.523	2.498 - 2.549	2.497	2.573
gcc-4.6 (O0, lto)	2.518	2.495 - 2.541	2.493	2.545
gcc-4.7 (O0)	2.553	2.529 - 2.577	2.532	2.577
gcc-4.7 (O0, lto)	2.541	2.518 - 2.563	2.519	2.571
llvm-3.1 (O0)	2.464	2.425 - 2.502	2.435	2.586
gcc-4.5 (O1)	1.525	1.508 - 1.541	1.509	1.548
gcc-4.6 (O1)	1.517	1.503 - 1.531	1.503	1.532
gcc-4.6 (O1, lto)	1.498	1.475 - 1.520	1.480	1.519
gcc-4.7 (O1)	1.469	1.452 - 1.487	1.452	1.505
gcc-4.7 (O1, lto)	1.484	1.469 - 1.500	1.468	1.504
llvm-3.1 (O1)	1.648	1.629 - 1.666	1.631	1.669
gcc-4.5 (O2)	1.443	1.423 - 1.462	1.428	1.484
gcc-4.6 (O2)	1.441	1.425 - 1.458	1.425	1.467
gcc-4.6 (O2, lto)	1.439	1.424 - 1.454	1.424	1.456
gcc-4.7 (O2)	1.456	1.439 - 1.473	1.441	1.478
gcc-4.7 (O2, lto)	1.443	1.424 - 1.462	1.428	1.491
llvm-3.1 (O2)	1.420	1.405 - 1.435	1.405	1.442
gcc-4.5 (O3)	1.424	1.408 - 1.440	1.408	1.448
gcc-4.6 (O3)	1.438	1.422 - 1.455	1.421	1.457
gcc-4.6 (O3, lto)	1.439	1.422 - 1.456	1.422	1.459
gcc-4.7 (O3)	1.443	1.427 - 1.459	1.426	1.462
gcc-4.7 (O3, lto)	1.442	1.425 - 1.460	1.429	1.467
llvm-3.1 (O3)	1.418	1.401 - 1.436	1.404	1.439
gcc-4.5 (OS)	1.568	1.549 - 1.588	1.552	1.591
gcc-4.6 (OS)	1.562	1.544 - 1.581	1.546	1.610
gcc-4.6 (OS, lto)	1.531	1.510 - 1.551	1.510	1.555
gcc-4.7 (OS)	1.563	1.547 - 1.579	1.544	1.582
gcc-4.7 (OS, lto)	1.566	1.550 - 1.583	1.549	1.587
llvm-3.1 (OS)	1.452	1.437 - 1.467	1.436	1.474

Nasledujúci graf je vizualizáciou tabuľky. Priemer je znázornený čiernou značkou. Obdĺžnik je 90% interval spoľahlivosti. Vrchné a spodné modré značky sú minimálnou a maximálnou nameranou hodnotou.

Kód prepísaný do C++ je na mojom stroji približne 60x rýchlejší než python kód.

Prvenstvo v rýchlosti kódu napriek mojim odhadom nezískalo g++ so zapnutou link time optimalizáciou, ale relatívne mladý kompilátor llvm s frontendom clang.

       

Komentáře

[tom]

Nechcete to prelozit a zmerit jeste pro pripad, kdy ma gcc k dispozici data z profileru (-fprofile-use)?

[mirec]

Profiler ma nenapadol. Ak na to nezabudnem doplním.

[mirec]

gcc 4.7 s -O3 a -lto má s -fprofile-use (samozrejme predtým som spúšťal s -fprofile-generate) prakticky totožné výsledky ako v testoch v blogu: priemer 1.4497, int. spoľahlivosti 90% 1.4283-1.4717, min 1.427, max 1.494.

[Radek Podgorny]

...a nema python na tyhle bitove hratky nejake moduly (tedy implementace v c)?

[mirec]

Na prácu s maticami a vektormi má celkom slušný balík numpy. Preberal som to s jedným pythonistom (ja som tiež programátor v pythone, ale robím skôr webové veci než algoritmy) a čiste teoreticky by sa to mohlo dať urýchliť použitím numpy. Problematické sú operácie na úrovni pixelov kde sa spracovanie podobá na fragment shadery na grafike. Teoreticky by sa to mohlo dať spracovať rozdelením bloku na 16 výškových vrstiev a potom pre každý pixel počítať farbu a aplikovať na pixmapu s maskovaním už vykreslených pixelov. Operácii by bolo síce viacej, ale vyhol by som sa tak podmieneným skokom. Na najnižšej úrovni by bolo vhodné funkciu aplikovanú na pixely prepísať do C.

[Michal Vyskočil]

Na najnižšej úrovni by bolo vhodné funkciu aplikovanú na pixely prepísať do C.

Ještě lepší variantu představuje cython, kde je snadné přepsat jenom tu kritickou část do ekvivalentního C-like staticky typovaného kódu.

[xanax]

takychto clankov by tu malo byt viac

[Heron]

Proč má každý blok svoji vlastní tabulku (to je tedy zřejmně onen druhý blok dat v jednom záznamu) materiálů?

Po prečítaní (a zahodení) metadát sa dostaneme k tabuľke materiálov. Každý blok má svoju vlastnú tabuľku materiálov

Jinak chválím použití SQLite. Je to lepší, než vymýšlet vlastní yet another db a potýkat se s problémy, které jsou už dávno vyřešené.

[mirec]

Proč má každý blok svoji vlastní tabulku (to je tedy zřejmně onen druhý blok dat v jednom záznamu) materiálů?

Neviem prečo má vlastnú tabuľku keď by sa to dalo riešiť goláblnou. Druhý blok komprimovaných dát sú metadáta, čo je key-value datastore na rôzne účely (napr. rôzne krabice, vlaky ... používajú položku "inventory" pre záznam objektov uložených v inom objekte). Tabuľka je uložená až za metadátami v nekomprimovanej forme.

Jinak chválím použití SQLite. Je to lepší, než vymýšlet vlastní yet another db a potýkat se s problémy, které jsou už dávno vyřešené.

Táto implementácia je len prenesenie pôvodnej súborovej implementácie do databázy. Prvé verzie mali mapu uloženú ako množstvo malých súborov s rovnakým názvom ako stĺpec pos v databáze a rovnakým obsahom ako stĺpec data.

SQLite je dobrá keď má obsluhovať jedného klienta. V minetest serveri sa mi zdá, že je diskové IO hlavnou prekážkou väčšieho množstva hráčov.

[Josef Kufner]

SQLite je dobrá keď má obsluhovať jedného klienta. V minetest serveri sa mi zdá, že je diskové IO hlavnou prekážkou väčšieho množstva hráčov.

S jakoukoliv databází na disku nemáš šanci. Tohle musíš udržet v paměti a čas od času (jednotky minut) udělat záložní kopii na disk. Pokud máš návaznost na okolní svět (jiná aplikace), tak pak držet záznam o provedených operacích pro případný rollback nebo rekonstrukci.

[Josef Kufner]

Btw, jak moc se takovýhle svět dá počítat na grafické kartě? IMHO se tady extrémní paralelismus docela hodí.

[mirec]

Niektoré operácie by určite išli krásne vektorizovať. Grafiky by mali byť aj celkom slušne optimalizované na z-buffer test. Výkon by podľa mňa mohlo zabiť len používanie asociatívnych polí, ale ak by CPU robil len načítavanie a preklad ID materiálov na farby a zvyšok by robila grafika mohlo by sa to tak o 50% zrýchliť (vychádzam z hodnôt nameraných callgrind-om).