To reduce your calc time on transformations create the local trans variable first then pass it along in calcuations: glm::mat4 trans = glm::mat4(1.0f); trans = glm::fucntion(trans,data) * glm::function(trans... I found this helped when I was moving 100's of objects in my engine and was hitting some insane lag
20:46 the ImGuiLayer stuff needs to be done if the window is minimized ... otherwise ImGui windows in their own viewport (outside our own application window) will stop responding you demonstrated that issue in your resizing video ;)
Hello there! In your game engine series it seems like you very much "buy into" the modern C++ style. This does not seem to be the case for most game devs I know of (Jonathan Blow comes to mind), as they seem to favor a more barebones, C-like, style Why do you think that is? What are the merits of each style?
@@joestevenson5568 this might not be the case for everything, as the guidelines for the standard C++ is zero overhead in execution. There are some containers and types that don't follow strictly (std::string comes to my mind) but in the end is about how much do you know C++ to know where the bottleneck in memory/cpu/gpu might be. Safety doesn't necessarily come with a time overhead when executing your software on C++. One area you can see this is the FILE* vs fstreams or templates for that matter, although the latter comes with a compilation time overhead.
How much performance hit does the actual instrumentation add? Especially if your adding string formatting as you add parameter values and there is the time it takes to physically write the performance data to file (assuming it in the same thread!). i.e the 'Uncertainty Principle' or 'Observer Effect' !
Introducing any kind of profiling, even when optimally implemented, causes in debug a (relatively) huge performance hit - even more when it's profiling functions in the hot patch (which you're mostly doing).
I was thinking that this type of profiling is good for doing relative performance testing and optimization, but you can't use it for absolute measurement. Saying that, it may be that the 'slow' modules/functions maybe slow because they are instrumentated. i.e a function that writes to the GPU may only be a few instructions. Once instrumentated, it becomes 10's or 100's of instructions, so the actual thing your measuring becomes a tiny percentage of the timed measurement! I guess like all things, you need to use these kind of methods sparingly and have an true understanding of what the measured data really means!
Wait, we need to profile the profiler! Seriously though, yes, it does add some impact. In most cases the strings are just shallow copies of a pointer to static data - so its pretty quick. If you start doing formatting of parameters though, or "processing" of the string to strip out "cdecl" or whatever, then the impact will be much much bigger. In my project I have preferred to use FUNCTION over FUNCSIG (so that I don't need to do any processing to remove the slightly ugly cdecl, and also results in smaller .json files. I use the funcsig variant only if I have a specific need to (like, I know the function is overloaded).
It adds alot of overhead, since on each profiling, it is writing to a file instead of caching it or something. I added a in engine Profiler window using ImGui, to display this information. From my testing: - using TheCherno Instrumentator that writes to a file, Sandbox2D::OnUpdate took me around 0.471 ms - using my in engine Profiler viewer that does not write to a file, Sandbox2D::OnUpdate took me around 0.257 ms Those gaps you see between "OrthographicCameraController:OnUpdate" and "Renderer Prep" are mostly IO (writing to the file), since on my Profiler in engine viewer you can hardly see the gaps.
I set up instrumentation on a couple of the Tests from many videos ago in this series. (The Test interface; onUpdate onRender onImGuiRender; using ImGui TestMenu to select between tests). Essentially, my measurements say that it takes 30-40 ms to create each Test. That's to create it. To construct it. That seems like a long time considering the size of the Test objects. Basically two frames to make one relatively small object. Is this 30-40 ms measurement reasonable?
There is a big difference between the "Intro to profiling" video and this video. Maybe there is a instrument preparation video or something like that. Is that right?
To reduce your calc time on transformations create the local trans variable first then pass it along in calcuations:
glm::mat4 trans = glm::mat4(1.0f);
trans = glm::fucntion(trans,data) * glm::function(trans...
I found this helped when I was moving 100's of objects in my engine and was hitting some insane lag
You are so strong Cherno, i wanna be like you. Cool programmer and cool guy. Great video and great explanation as usual.
20:46 the ImGuiLayer stuff needs to be done if the window is minimized ... otherwise ImGui windows in their own viewport (outside our own application window) will stop responding
you demonstrated that issue in your resizing video ;)
I was also like wait wut :D
Hello there!
In your game engine series it seems like you very much "buy into" the modern C++ style. This does not seem to be the case for most game devs I know of (Jonathan Blow comes to mind), as they seem to favor a more barebones, C-like, style
Why do you think that is? What are the merits of each style?
Performance vs safety.
@@joestevenson5568 this might not be the case for everything, as the guidelines for the standard C++ is zero overhead in execution. There are some containers and types that don't follow strictly (std::string comes to my mind) but in the end is about how much do you know C++ to know where the bottleneck in memory/cpu/gpu might be.
Safety doesn't necessarily come with a time overhead when executing your software on C++. One area you can see this is the FILE* vs fstreams or templates for that matter, although the latter comes with a compilation time overhead.
Great video, very insightful and such a useful tool
How much performance hit does the actual instrumentation add? Especially if your adding string formatting as you add parameter values and there is the time it takes to physically write the performance data to file (assuming it in the same thread!). i.e the 'Uncertainty Principle' or 'Observer Effect' !
i am thinking that too
Introducing any kind of profiling, even when optimally implemented, causes in debug a (relatively) huge performance hit - even more when it's profiling functions in the hot patch (which you're mostly doing).
I was thinking that this type of profiling is good for doing relative performance testing and optimization, but you can't use it for absolute measurement. Saying that, it may be that the 'slow' modules/functions maybe slow because they are instrumentated. i.e a function that writes to the GPU may only be a few instructions. Once instrumentated, it becomes 10's or 100's of instructions, so the actual thing your measuring becomes a tiny percentage of the timed measurement! I guess like all things, you need to use these kind of methods sparingly and have an true understanding of what the measured data really means!
Wait, we need to profile the profiler! Seriously though, yes, it does add some impact. In most cases the strings are just shallow copies of a pointer to static data - so its pretty quick. If you start doing formatting of parameters though, or "processing" of the string to strip out "cdecl" or whatever, then the impact will be much much bigger. In my project I have preferred to use FUNCTION over FUNCSIG (so that I don't need to do any processing to remove the slightly ugly cdecl, and also results in smaller .json files. I use the funcsig variant only if I have a specific need to (like, I know the function is overloaded).
It adds alot of overhead, since on each profiling, it is writing to a file instead of caching it or something.
I added a in engine Profiler window using ImGui, to display this information.
From my testing:
- using TheCherno Instrumentator that writes to a file, Sandbox2D::OnUpdate took me around 0.471 ms
- using my in engine Profiler viewer that does not write to a file, Sandbox2D::OnUpdate took me around 0.257 ms
Those gaps you see between "OrthographicCameraController:OnUpdate" and "Renderer Prep" are mostly IO (writing to the file), since on my Profiler in engine viewer you can hardly see the gaps.
Hey, I wonder if you'll ever do Vulkan tutorials.
Would you please do a tutorial explaining what’s CMake for beginners .
thanks!
Great video. Thanks. you are awesome
I set up instrumentation on a couple of the Tests from many videos ago in this series.
(The Test interface; onUpdate onRender onImGuiRender; using ImGui TestMenu to select between tests).
Essentially, my measurements say that it takes 30-40 ms to create each Test. That's to create it. To construct it.
That seems like a long time considering the size of the Test objects. Basically two frames to make one relatively small object.
Is this 30-40 ms measurement reasonable?
great
Mentioned fixing the timer multiple times but didn’t. Is it addressed in another video, if so which one?
There is a big difference between the "Intro to profiling" video and this video. Maybe there is a instrument preparation video or something like that. Is that right?
there is a video before this one not added in the playlist.
At first, I thought my video was running on 1.5x
What is the name of the song that plays at the end of the video, somebody could tell me?
Thank you.
@@Rodrigo-dx4pm You are welcome.
I am waiting for another "day in the life".
Is __PRETTY_FUNCTION__ better then __FUNCSIG__?
25:42 That's half a millisecond, not 510 ms ;) Or 498ms of wall time, of course.
can u do a small game tutorial
just a simple 2d game with any library
Bruh