[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Measuring Enigma's performance: A paradox?

From: Daniel Heck
Subject: Re: Measuring Enigma's performance: A paradox?
Date: Sun, 11 Apr 2021 11:24:48 +0200

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]