Zobrazit předchozí téma :: Zobrazit následující téma |
Autor |
Zpráva |
perry
Založen: 28. 07. 2009 Příspěvky: 879
|
Zaslal: 21. duben 2014, 17:46:23 Předmět: Profiling |
|
|
Co používáte na profilování kódu (C++, OpenGL) ?
C++
Visual Studio Profiler... ale není to úplně ono
Grafika:
Zkoušel jsem pro OpenGL gDebugger a ten je takový.. no.. "meh"
NSight po mě zase chce na pořádnou akci drihé GPU
Nějaké další tipy & triky ? _________________ Perry.cz |
|
Návrat nahoru |
|
|
Ladis
Založen: 18. 09. 2007 Příspěvky: 1536 Bydliště: u Prahy
|
Zaslal: 21. duben 2014, 18:07:25 Předmět: |
|
|
Podle mě nic není úplně ono. _________________ Award-winning game developer |
|
Návrat nahoru |
|
|
Vilem Otte
Založen: 18. 09. 2007 Příspěvky: 462 Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
Zaslal: 21. duben 2014, 18:52:52 Předmět: |
|
|
Nic není ideální. Osobně na tučňáčkovi gprof, na woknech VS Profiler. U D3D je situace o něco lepší afaik. _________________ Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012 Příspěvky: 608
|
Zaslal: 21. duben 2014, 18:54:55 Předmět: Re: Profiling |
|
|
Na profilování kódu třeba Very Sleepy http://www.codersnotes.com/sleepy
Je to sample-based profiler (myslím, že něco podobného máš i ve VS).
Obecně mám radši sample-based profilery (pokud máš dost vzorků , nemusíš instrumentovat kód a stačí ti povolit generování debug infa a výsledky mi přijdou důvěryhodnější (plus nezpomaluje to zdaleka tolik).
Nejdůležitější je podle mě asi výsledky správně interpretovat.
Nedávno jsem psal vlastní memory allocator (a to jsem před časem radil nepsat si vlastní - Microsoftí defaultní v CRT (HeapAlloc/...) mě totiž opět zklamal kvůli fragmentaci virtual address space, je to vůbec možné v roce 2014?!!!)
a profiler mi pomohl identifikovat problém: O(log n) není tak dobrý jako O(1) - budu muset zapracovat a zalgoritmizovat rozdělení do bucketů, i když pro mé účely už je dostačující.
Na profilování GL používám FPS counter s vypnutým VSYNCem Pokud chceš změřit to, kde se čeká na synchronizaci, tak třeba ve VS máš concurrency visualizer (threads, pak najdi vlákno, ve kterém posíláš příkazy driveru a synchronizace je červenou). |
|
Návrat nahoru |
|
|
perry
Založen: 28. 07. 2009 Příspěvky: 879
|
Zaslal: 21. duben 2014, 19:01:22 Předmět: |
|
|
No já právě v tom profileru ve VS zjistil, že můj kód nejvíce "brzdí" std::map - až 40% všech volání leze do mapy a používá strcmp (mám mapu na stringy na mapování proměnných z shaderů). Akorát nevím jak moc tomu můžu věřit, tak hledám i něco jiného v čem to změřit
(plus asi nastal čas hodit tam C++11 a unordered_map) _________________ Perry.cz |
|
Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012 Příspěvky: 608
|
Zaslal: 21. duben 2014, 19:20:43 Předmět: |
|
|
perry napsal: |
No já právě v tom profileru ve VS zjistil, že můj kód nejvíce "brzdí" std::map - až 40% všech volání leze do mapy a používá strcmp (mám mapu na stringy na mapování proměnných z shaderů). Akorát nevím jak moc tomu můžu věřit, tak hledám i něco jiného v čem to změřit
(plus asi nastal čas hodit tam C++11 a unordered_map) |
40% se mi zdá hodně je to opravdu 40% času?
Jak jsem psal, O(log n) není O(1), takže unordered_map bych určitě zkusil a porovnal výsledky.
Počítám, že tam na dotaz sypeš stringové literály (pokud ne, dalo by se to vylepšit třeba použitím globální name table, tj. dáš mu string a on ti vrátí index a ten pak použít jako klíč nebo cachováním hashe, pokud máš vlastní stringy). |
|
Návrat nahoru |
|
|
perry
Založen: 28. 07. 2009 Příspěvky: 879
|
Zaslal: 21. duben 2014, 19:31:33 Předmět: |
|
|
Jj.. 40% času.. jako mám tam mapy skoro všude, všechno mám indexované přes stringové klíče.
Mám vlastní string, a na co používá std::map musím použít strcmp. Pro hash tam mám "cachovaný" výpočet. Spočte se to jednou a pak to visí v paměti dokud ten string nezměním (pokud ano, on demand se vypočte nový hash). Takže by to pak mělo být rychlejší. Ty nejčastěji používané stringy mám uložené v globálních proměnných jako předem vygenerované klíče (např. MyString WORLD_MATRIX = "mWorld"), další pak uložím do nějakého listu při inicializaci třídy a dál pracuji s referencemi. _________________ Perry.cz |
|
Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012 Příspěvky: 608
|
Zaslal: 21. duben 2014, 19:49:18 Předmět: |
|
|
Tak to je ideální - v tom případě budeš mít jednoduchou práci a stačí to změnit všude na unordered_map |
|
Návrat nahoru |
|
|
rezna
Založen: 27. 07. 2007 Příspěvky: 2156
|
Zaslal: 22. duben 2014, 07:41:28 Předmět: |
|
|
1) to je hodne, nejsi nahodou v debugu?
2) udelej si vlastni comparer pro std::map a nemusis resit strcmp()
3) neco jineho zkus - treba khash - nedavno na tohle tema byl clanek na hackernews - srovnani unsorted_map, khash a a dalsich (vcetne Java a C#) |
|
Návrat nahoru |
|
|
perry
Založen: 28. 07. 2009 Příspěvky: 879
|
Zaslal: 22. duben 2014, 08:24:19 Předmět: |
|
|
Jo.. bylo to v debugu (ono jde profilovat v Release ?) Ale i tak, přijde mi zbytečné mít tam std::map, když jsou ty stringy neměnné a hash spočtu jednou a pak mám O(1).. tady mám pořád O(log n), ať dělám co dělám... a na sortu nesejde.
Navíc je do pro mě dobrý důvod konečně přejít na C++11 a Visual Studio 2013 (ačkoliv ten design je humáč) _________________ Perry.cz |
|
Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012 Příspěvky: 608
|
Zaslal: 22. duben 2014, 10:02:34 Předmět: |
|
|
perry napsal: |
Jo.. bylo to v debugu (ono jde profilovat v Release ?) |
Aha Dobrá poznámka, to mě nenapadlo. No ono totiž v debugu profilovat moc smysl nemá.
Máš tam hromadu assertů plus vyplé optimalizace, takže to pak vůbec nemusí odpovídat skutečnosti. |
|
Návrat nahoru |
|
|
OndraSej
Založen: 28. 07. 2007 Příspěvky: 767 Bydliště: Brandýs nad Labem
|
Zaslal: 22. duben 2014, 12:46:23 Předmět: |
|
|
perry> pro rozumne profilovani potrebujes symbolicke nazvy funkci a metod, ale jejich export je (v rozumnem prekladaci by mel byt) nezavisly na zbytku optimalizaci. Samozrejme ve vysledcich neuvidis spravne casy pro inlinovane funkce, ale zakladni prehled z toho ziskas. _________________ http://trionteam.net |
|
Návrat nahoru |
|
|
rezna
Založen: 27. 07. 2007 Příspěvky: 2156
|
Zaslal: 22. duben 2014, 12:48:40 Předmět: |
|
|
tak tak, profiluje se vzdy release verze se symbolama
zrovna STL je neuveritelne pomaly v debug verzi |
|
Návrat nahoru |
|
|
]semo[
Založen: 29. 07. 2007 Příspěvky: 1526 Bydliště: Telč
|
Zaslal: 22. duben 2014, 15:13:24 Předmět: |
|
|
Jen taková poznámka: mě nepřipadá, že zmíněných 40% času v std::map je nějak moc. Když nezmíníš co všechno ten program dělá a jak dlouho to vlastně trvá, tak ten údaj neříká nic moc. Pokud máš jen grafiku bez ničeho, kterou vykresluješ pořád dokola, tak většinu času trávíš plněním proměnných pro shadery a přepínáním stavů. Zbytek je čekání na vykreslení.
Jinak samozřejmě: debugovat potřebuješ jen ten nejostřejší release a bez debuggeru (čili pokud to nějak spouštíš z VS, tak Ctrl+F5). _________________ Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory |
|
Návrat nahoru |
|
|
perry
Založen: 28. 07. 2009 Příspěvky: 879
|
Zaslal: 22. duben 2014, 21:19:23 Předmět: |
|
|
Tak ta std::unordered_map to trochu zlepšila.
Co se týče profilingu v Release módu, tak vytížení CPU je stejné akorát se volání přesunula někam jinak, resp. k nějakým glFunkcím. Nicméně přechodu na C++11 nelituji, projel jsem si novinky a vypadá to dobře. Jediné, co je smůla, je hnusné Visual Studio 2013 _________________ Perry.cz |
|
Návrat nahoru |
|
|
|