It was a game that clearly advanced the state of the art. Even in the month before it came out, people were claiming it simply could not be done technically on the underpowered PC technology of that time. Even after it came out, it took others a year to catch up.
Expectations at release were sky high, and Doom still overdelivered. The tech, the gameplay, the esport aspect, the gritty graphics theming. It was all new and daring.
The BSP was an obscure thing nobody understood. It took the DEU people months to wrap their heads around the NODES datastructure.
When the modding tools were finally available, the whole world became 1 big modding community for the same game. That amount of focus on 1 game has never happened before or since. Modding continues to this day, 30 years later.
Then the source code was delivered, for free, to everyone. It was easily readable and told every secret. We all went crazy. It was studied by every programming student. Even today, no other codebase has the same amount of scrutinity, with every bug and detail documented.
Myhouse.wad was a great example of how far a doom mod can be pushed. But it is also a testament to the collective midlife crisis of the doomers from that age, all of us yearning for the good old days.
It’s not an obsession, it’s probably because Doom is easy to understand from a code perspective, and also addresses a lot of graphical/game code techniques, aka its a perfect hobby from a coding perspective to learn, adapt and tweak. It’s actually the perfect example of Hacking.
Also this hacking started early on, so there is probably tons and tons of documentation and data, again making it a great candidate to work with it from a hacking perspective.
Pretty cool seeing people actually care so much about profiling tools. You think we ever get one tool that really covers enough to keep everyone happy?
Flamegraphs are neat but the call graph in Luke Stackwalker[0] was more immediately obvious to me (especially since it draws a thick red line for the hottest path) than them.
Another approach is one i used for a profiler i wrote some time ago (and want to port to Linux at some point)[1] which displays the hottest "traces" (i.e. callstacks). One neat aspect of this is that you can merge multiple traces using a single function as the "head" (so, e.g., if there are two separate traces that contain a function "Foo" somewhere, you can select to use "Foo" as the starting point and they'll be treated as the same trace with their hitcounts combined).
I’ll be honest, I kinda don’t get flame graphs. I mean I understand what they are. I have just always strictly preferred a proper timeline view ala Superluminal or Tracy.
Using 20ms chunks for a game is fine but also super weird. Ain’t no game using 20ms frames! So if you were using this for real you’d get all kinds of oddities. Just give me a timeline and call it a day plz.
The origin problem for flame graphs was MySQL server performance involving dozens of threads: as a timeline view you need dozens of timelines, one for each thread, since if you render it on one (I know this is probably obvious) then you have samples from different threads from one moment to the next turning the visualization into hair. Flame graphs scale forever and always show the aggregate: any number of threads, servers, microservices, etc.
I think great UI should do both: have a toggle for switching between flame graphs (the summary) and timelines (aka "flame charts") for analyzing time-based patterns. I've encouraged this before and now some do provide that toggle, like Firefox's profiler (Flame Graphs and Stack Charts for timeline view).
As for 20ms, yes, we do want to take it down. A previous HN comment from years ago, when I first published FlameScope, was to put a game frame on the y-axis instead of 1 second, so now each column shows the rendering of a game frame, and you can see time-offset patterns across the frames (better than a time-series timeline). We started work on it and I was hoping to include it in this post. Maybe next one.
I’ve never actually seen a profiler that shows quite what I want. I have lots of subsystems running at different rates. Gameplay at 30Hz, visual render at 90Hz, physics at 200Hz, audio at some rate, network, some device, etc.
So what I want is the ability to view each subsystem in a manner that lets me see when it didn’t hit its update rate. I have many many different frame rates I care about hitting.
Of course things even get more complex when you have all the work broadly distributed with a job system…
The difference between a flame graph and a trace visualization is that a flame graph is a aggregate/summary visualization. It helps visualize total runtime attributed to functions.
It is like the difference between seeing the mean of a distribution and seeing a plot of every datapoint in the distribution. They are useful for different purposes.
An example of how you might use it in conjunction with a trace visualizer is that you would select a time span in a trace and generate a flame graph for the selection. This would show you which functions and call stacks were responsible for most of the execution time in the selection. You would then use that to find one of those call stacks in the trace to examine how they execute to see if it makes sense.
I could just regenerate these heat maps with 60 rows instead of 50. I'm limited by the sampling rate that was captured in the profile data file. To provide even more resolution (so you had many samples within a game frame) I'd need to re-profile the target with a higher frequency.
When Martin, my colleague at Netflix at the time, built a d3 version of FlameScope, he put a row selector in the UI: https://github.com/Netflix/flamescope
It sounds like your problem might be not with the visualization itself, but with the underlying idea of a sampling profiler as opposed to tracing every single call from every single frame.
No. Sampling profilers are great. Most powerful is of course a mix of sampling and instrumentation. But nothing beats the feeling of a sampling profiler fixing big issues in under 5 minutes.
Flamegraphs are a nice tool to have in the bag I suppose. But they’re more tertiary than primary or even secondary to me.
The game model might involve 20ms time slices. The frame rate is simply the best available visualisation of the "action" that the machine can manage.
So, you have your game model, input and output. Output needs to be good enough to convince you that you are in control and immersive enough to keep you engaged and input needs to be responsive enough to feel that you are in control. The model needs to keep track of and co-ordinate everything.
I'm old enough to still own a Commodore 64 and before that I played games and wrote some shit ones on ZX 80, 81 and Speccies. I typed in a lot of DATA statements back in the day (40 odd years ago)!
When you pare back a game to the bare basics - run it on a box with KB to deal with instead of GB - you quite quickly get to understand constraints.
Things are now way more complicated. You have to decide whether to use the CPU or the GPU for each task.
Flame graphs are definitely less sophisticated than Superluminal/Tracy/etc, but that's a part of the attraction - you can visualize the output of many profiling tools as a flamegraph without prior setup. I also think it's a pretty good UX for the "which function is the performance bottleneck" game.
May be I am too young but can someone explain this obsession with Doom on Hacker News?
I've lived trough the doom craze. My perspective:
It was a game that clearly advanced the state of the art. Even in the month before it came out, people were claiming it simply could not be done technically on the underpowered PC technology of that time. Even after it came out, it took others a year to catch up.
Expectations at release were sky high, and Doom still overdelivered. The tech, the gameplay, the esport aspect, the gritty graphics theming. It was all new and daring.
The BSP was an obscure thing nobody understood. It took the DEU people months to wrap their heads around the NODES datastructure.
When the modding tools were finally available, the whole world became 1 big modding community for the same game. That amount of focus on 1 game has never happened before or since. Modding continues to this day, 30 years later.
Then the source code was delivered, for free, to everyone. It was easily readable and told every secret. We all went crazy. It was studied by every programming student. Even today, no other codebase has the same amount of scrutinity, with every bug and detail documented.
Myhouse.wad was a great example of how far a doom mod can be pushed. But it is also a testament to the collective midlife crisis of the doomers from that age, all of us yearning for the good old days.
It’s not an obsession, it’s probably because Doom is easy to understand from a code perspective, and also addresses a lot of graphical/game code techniques, aka its a perfect hobby from a coding perspective to learn, adapt and tweak. It’s actually the perfect example of Hacking.
Also this hacking started early on, so there is probably tons and tons of documentation and data, again making it a great candidate to work with it from a hacking perspective.
Love the screenshot with the million shotgunners and cyberdemons, and a chainsaw.
A few comments, 2 days ago
https://news.ycombinator.com/item?id=43846283
Pretty cool seeing people actually care so much about profiling tools. You think we ever get one tool that really covers enough to keep everyone happy?
Considering that I hate flamegraphs probably not
What’s your preferred way of visualising performance?
Flamegraphs are neat but the call graph in Luke Stackwalker[0] was more immediately obvious to me (especially since it draws a thick red line for the hottest path) than them.
Another approach is one i used for a profiler i wrote some time ago (and want to port to Linux at some point)[1] which displays the hottest "traces" (i.e. callstacks). One neat aspect of this is that you can merge multiple traces using a single function as the "head" (so, e.g., if there are two separate traces that contain a function "Foo" somewhere, you can select to use "Foo" as the starting point and they'll be treated as the same trace with their hitcounts combined).
[0] https://lukestackwalker.sourceforge.net/
[1] http://runtimeterror.com/tools/fpwprof/index.html
Depends but if it's samples I'd usually reach for a hierarchical outline view. If it's time series data then probably a bunch of tracks.
Is it possible to make Doom in the GPU flame graphs?
Neat.
I’ll be honest, I kinda don’t get flame graphs. I mean I understand what they are. I have just always strictly preferred a proper timeline view ala Superluminal or Tracy.
Using 20ms chunks for a game is fine but also super weird. Ain’t no game using 20ms frames! So if you were using this for real you’d get all kinds of oddities. Just give me a timeline and call it a day plz.
The origin problem for flame graphs was MySQL server performance involving dozens of threads: as a timeline view you need dozens of timelines, one for each thread, since if you render it on one (I know this is probably obvious) then you have samples from different threads from one moment to the next turning the visualization into hair. Flame graphs scale forever and always show the aggregate: any number of threads, servers, microservices, etc.
I think great UI should do both: have a toggle for switching between flame graphs (the summary) and timelines (aka "flame charts") for analyzing time-based patterns. I've encouraged this before and now some do provide that toggle, like Firefox's profiler (Flame Graphs and Stack Charts for timeline view).
As for 20ms, yes, we do want to take it down. A previous HN comment from years ago, when I first published FlameScope, was to put a game frame on the y-axis instead of 1 second, so now each column shows the rendering of a game frame, and you can see time-offset patterns across the frames (better than a time-series timeline). We started work on it and I was hoping to include it in this post. Maybe next one.
I’ve never actually seen a profiler that shows quite what I want. I have lots of subsystems running at different rates. Gameplay at 30Hz, visual render at 90Hz, physics at 200Hz, audio at some rate, network, some device, etc.
So what I want is the ability to view each subsystem in a manner that lets me see when it didn’t hit its update rate. I have many many different frame rates I care about hitting.
Of course things even get more complex when you have all the work broadly distributed with a job system…
The difference between a flame graph and a trace visualization is that a flame graph is a aggregate/summary visualization. It helps visualize total runtime attributed to functions.
It is like the difference between seeing the mean of a distribution and seeing a plot of every datapoint in the distribution. They are useful for different purposes.
An example of how you might use it in conjunction with a trace visualizer is that you would select a time span in a trace and generate a flame graph for the selection. This would show you which functions and call stacks were responsible for most of the execution time in the selection. You would then use that to find one of those call stacks in the trace to examine how they execute to see if it makes sense.
I think flame graphs are perfect for what they do, compressing multi dimensional data down into fewer dimensions.
It makes it a lot easier to visualise at a glance, and sometimes an issue is obvious from the flame graph.
But you're right, for complex issues I find I need to dig deeper than that and view everything linearly.
They're just nice for glaring issues, it's like a mini dashboard almost.
> Ain’t no game using 20ms frames!
A frame every 20ms equates to 50 frames per second. Doesn't seem too unreasonable for a modern game.
60 frames per second would be one frame every ~16 ms.
Correct. Which means that every 20ms pixel slices two or three frames. Which is a really really bad way to profile!
I could just regenerate these heat maps with 60 rows instead of 50. I'm limited by the sampling rate that was captured in the profile data file. To provide even more resolution (so you had many samples within a game frame) I'd need to re-profile the target with a higher frequency.
When Martin, my colleague at Netflix at the time, built a d3 version of FlameScope, he put a row selector in the UI: https://github.com/Netflix/flamescope
It sounds like your problem might be not with the visualization itself, but with the underlying idea of a sampling profiler as opposed to tracing every single call from every single frame.
No. Sampling profilers are great. Most powerful is of course a mix of sampling and instrumentation. But nothing beats the feeling of a sampling profiler fixing big issues in under 5 minutes.
Flamegraphs are a nice tool to have in the bag I suppose. But they’re more tertiary than primary or even secondary to me.
Timelines are good when things happen once, but when you have repeated calls to functions from different places etc., a flame graph helps a lot.
Sandwich views supporting collapsing recursion are the secret sauce for flame graphs imo. See e.g,. https://pyroscope.io/blog/introducing-sandwich-view/
The game model might involve 20ms time slices. The frame rate is simply the best available visualisation of the "action" that the machine can manage.
So, you have your game model, input and output. Output needs to be good enough to convince you that you are in control and immersive enough to keep you engaged and input needs to be responsive enough to feel that you are in control. The model needs to keep track of and co-ordinate everything.
I'm old enough to still own a Commodore 64 and before that I played games and wrote some shit ones on ZX 80, 81 and Speccies. I typed in a lot of DATA statements back in the day (40 odd years ago)!
When you pare back a game to the bare basics - run it on a box with KB to deal with instead of GB - you quite quickly get to understand constraints.
Things are now way more complicated. You have to decide whether to use the CPU or the GPU for each task.
Flame graphs are definitely less sophisticated than Superluminal/Tracy/etc, but that's a part of the attraction - you can visualize the output of many profiling tools as a flamegraph without prior setup. I also think it's a pretty good UX for the "which function is the performance bottleneck" game.
Loads of older console games used 20ms fields in Europe.
Edit: also my laptop can, but I'm not into that sort of thing.