You then open your recorded session in a standalone application called the Telemetry Visualizer, which is basically the coolest thing ever. Running your program with Telemetry causes it to output data to a stand-alone server application, which whirs away in the background recording what your program is doing.
Integrating the library into our codebase turned out to be pretty easy, taking about half an hour of work to get good profiler coverage. Unlike VTune, which tries to run on a codebase without markup, Telemetry asks you to manually label your C++ codebase with little snippets of code to indicate what different parts of your codebase do in context: “drawing skeletal animation”, “shaving the yak”, “flushing the pnorb”, etc. It may have been doing useful things with the data, but there was no real way to narrow down what in the world was actually going on. For the most part, VTune failed to tell me anything interesting at all. VTune integrates nicely into Visual C++, and you run the profiler from within the application. I have worked with previous versions of VTune, most notably back in 2001 when I was trying (and failing) to optimize The Lithtech Engine. Intel’s VTune operates from Microsoft Visual C++ 2012. Think of it as a tenuous thematic connection. These actually have nothing to do with what Nicholas is doing but It Was Decided that the post needed some more visual accompaniment. Finally, we tried our luck with NVidia’s GPU Perfstudio to see if we could figure out what was happening on the graphics card. There were three solutions for profiling that we looked at: Intel’s VTune, what we might call a ‘classical’ profiler which you can download a 30-day trial of from their website, and Telemetry, a different sort of profiler made by RAD Game Tools (specifically by Brian Hook, who you might know from such games as Quake 3.) RAD Game Tools also provided us with a 30-day trial of Telemetry, and this gave me an interesting opportunity to compare two profilers. Finally, sick and tired of the problems, I decided to get some answers. I don’t like optimizing too early – as Donald Knuth pointed out famously, “premature optimization is the root of all evil” – but something was going on. On Chris Whitman’s machine, which uses a slightly different graphics card than my computer, our FPS was in single digits. We recently discovered that the game was running… unreasonably slowly, shall we say? My desktop was getting 15 FPS, and it wasn’t clear what the problem was. There are lots of complex, interconnected moving parts to worry about and when something goes wrong, it can be hard to figure out where that small, broken thing is in the midst of a larger picture.
It’s not easy writing a complicated simulation.
0 kommentar(er)
