#Member vs local variables

32 messages · Page 1 of 1 (latest)

tribal hound
#

I know someone that has been doing programming for a long time, developed many android games and stuff, and he is insisting that Test1::run causes heating issues after 3-4 hours, but after changing the int i; to a member variable (as seen in Test2::run), the heating issue is fixed. And I don't believe quite him, it just doesn't make sense, it has more instructions. Mentioned behavior is on an android game. I wanted to hear what people here think about this, especially people with experience on older android devices.

class Test1 {
public:
    void run() {
        for (int i = 0; i < 100; i++) {
            std::cout << i;
        }
    }
};


class Test2 {
public:
    void run() {
        for (i = 0; i < 100; i++) {
            std::cout << i;
        }
    }

private:
    int i;
};
primal meadowBOT
#

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

half lava
#

causes heating issues after 3-4 hour
what

tribal hound
#

That was my initial reaction

half lava
#

it is also my final reaction

tribal hound
#

My thought was that they accidentally changed something else and that other change fixed the issue. Or perhaps the framerate was not capped and this reduced the framerate and caused the GPU to do less, and it may have resulted in less heating on a particular device? I would really love to be able to replicate this if it's actually real.

He is saying that they tried this on 20-25k different device models (not devices!).

half lava
tribal hound
half lava
#

one way this can go wrong is to write a loop that actually has undefined behavior (e.g. because it causes data races) which is then optimized in such a way that it will run infinitely or do anything else really

tribal hound
#

But I'm working on optimizing the game engine he developed, which is open source. I made a change that reverted this member variable and he complained that this is not better

half lava
#

if at all this is hiding a symptom of a deeper problem

#

in fact, if the program has well-defined behavior, using the member will make it less performant and cause more waste heat as a consequence

tribal hound
#

It also causes confusion, there was a code like this;

// On recalculateBoundingBox, inside a for that loops each mesh
bbverticies = mesh.getVerticies();

// On class's member variables
std::vector<Vertex> bbvertices;

This is something I spotted and fixed, which gained us a lot of framerates

tribal hound
half lava
#

I can't tell from what you are showing, I guess it is either an incorrect way to attempt to sleep somewhere or incorrect synchronization between threads, if multiple threads are involved

tribal hound
#

Multithreadding is not involved, at least

tribal hound
tribal hound
half lava
#

then the other thing I said: some incorrect attempt at sleeping/waiting for the next frame

tribal hound
#

Hmm, you might be onto something, if they did the same thing on preciseSleep (which exists in the engine to limit the framerate by sleeping), it might not be doing the busy wait part straight up skipping to the thread sleep on full time. Which might actually reduce heating?

half lava
tribal hound
# half lava > busy wait makes my alarms go off, how is that implemented? 
void gAppManager::preciseSleep(double seconds) {
    G_PROFILE_ZONE_SCOPED_N("gAppManager::preciseSleep()");
    double estimate = 5e-3;
    double mean = 5e-3;
    double m2 = 0;
    double count = 1;
    double observed = 0;
    double delta = 0;
    double stddev = 0;

    while (seconds > estimate) {
        AppClockTimePoint start = AppClock::now();
        std::this_thread::sleep_for(std::chrono::milliseconds(1));
        AppClockTimePoint end = AppClock::now();

        observed = (end - start).count() / 1'000'000'000.0;
        seconds -= observed;

        count++;
        delta = observed - mean;
        mean += delta / count;
        m2 += delta * (observed - mean);
        stddev = std::sqrt(m2 / (count - 1));
        estimate = mean + stddev;
    }

    // spin lock
    AppClockTimePoint start = AppClock::now();
    while ((AppClock::now() - start).count() / 1'000'000'000.0 < seconds);
}

This is the current implementation, old one was probably lot more different. Trying to find it

#

A lot of red flags, I don't agree on lot of decisions they do while developing this engine and projects with it, especailly the flatcase naming scheme for variables is straight up pointless to me

half lava
#

I don't get what that is attempting to achieve, but mean is not actually a mean of the measured wait times and neither is stddev a standard deviation of it.

tribal hound
#

I don't either, it is what it is lol. It works so one one really touches it

half lava
#

Well, I could potentially see reordering issues if AppClock::now() is not implemented correctly.

tribal hound
#

I think thats just an alias

half lava
#

for the standard library?

tribal hound
#

Yeah

    using AppClock = std::chrono::steady_clock;
    using AppClockDuration = AppClock::duration;
    using AppClockTimePoint = AppClock::time_point;

Well anyways, you don't really need to spend time analyzing the code because this is what we currently have and the experience he had was probably in another engine.

#

I don't think we can solve this unless we see the diff between two versions of that game & engine.

#

!solve

primal meadowBOT
#

Thank you and let us know if you have any more questions!

This thread is now set to auto-hide after an hour of inactivity