Re: Measuring Enigma's performance: A paradox?

[address@hidden]

With the statusbar closed, there's more screen real estate to update, no?

On Sun, Apr 11, 2021 at 11:24 AM Daniel Heck <mail@dheck.net> wrote:

Hm... it's hard to know what's going on without more information. Have you tried using a profiler (e.g. "gprof" or "oprofile" on Linux) to figure out _where_ the time is being spent? In general, I find CPU time to be a relatively poor proxy for performance, not just because it is influenced by things like CPU scaling, but also because it usually doesn't account for time spent waiting (I/O, memory, external devices) and time spent in other parts of the system (the operating system, hardware drivers, other processes).

That being said, Enigma's rendering "engine" is indeed antiquated and not a good fit for the way modern computers update the screen. Rendering in software and uploading the resulting image to the GPU is simply not efficient any more. Ideally, we would use the SDL_Render API to let the GPU do all of the drawing so that we have to transfer as little image data between the CPU and the GPU as possible. But this would require a significant rewrite of the display code...

Now that I think of it, have your experimented with the way screen updates are handled in ecl::Screen:flush_updates()? When there are more than 200 updated regions on the screen, the function simply updates its entire contents, which might be related to your observation that drawing more is faster.

- Daniel

> On 10. Apr 2021, at 18:23, Andreas Lochmann <and.lochmann@googlemail.com> wrote:
>
> Hi everyone,
>
> I'm currently performing some experiments to improve Enigma's performance in the graphics department. For this, I measure the CPU time used to solve certain self-solving levels, particularly one with smooth scrolling, because this is our Achilles' heel right now.
>
> I noticed that Enigma uses less CPU time when something else runs in the background, like a web video. This is easily explained by the CPU frequency stepping up. However, it seems like this effect appears even when I activate/deactivate the Enigma's own status bar (the one counting up the time and displaying the level title) and full utilisation. Let me explain:
>
> I first launched several prime generators in the background, so my cores were 100% utilised and CPU frequency on its maximum. With status bar activated, Enigma uses on average 13.05 CPU-seconds for a specific task. When I completely deactivate the status bar, the same task takes about 13.87 CPU-seconds -- and this although drawing the status bar itself has to be done within the same 13.05 CPU-seconds. (This is not a statistical fluke. For the average I used four runs each time, and all four runs WITH status bar needed consistently less time than WITHOUT status bar. And I did similar, slightly different experiments before, all showing the same paradoxical behaviour.)
>
> How can it be that drawing the status bar still leads to less CPU time used? Is "video memory cache in CPU" a thing? (Remember that Enigma relies on software acceleration for graphics.)
>
> Maybe someone of you knows this and can help me out?
>
> Because: If this turns out to be real, it might make Enigma faster if it has to draw more on each time step. After all, we have lots of code trying to reduce the blit count.