Jump to content

  • Log In with Google      Sign In   
  • Create Account

Pink Horror

Member Since 02 Jul 2013
Offline Last Active Today, 02:15 PM

Posts I've Made

In Topic: Finding that balance between optimization and legibility.

19 July 2016 - 07:17 PM


Except when the calculations actually outweight the cost of a mispredicted branch... right? I'm not sure on the details, but shouldn't this misprediction cost be something like ~100 cycles on modern desktop CPUs? So if you can skip calculations that take significantly longer than that, a branch is the better choice.


Also on desktop, branches that are easy to predict have very little cost. Like something that checks for an memory allocation error that when thrown will terminate the program, the branch will always be false anyways so the only cost should be the branching operation itself. Thats different on consoles where there is no branch prediction (I don't think the current generation added it, did they?), but I didn't program on consoles myself so far so I can't say much about it.


They did add branch prediction.

In Topic: Overall Strategy For Move-Semantics? [C++11]

19 July 2016 - 06:56 PM

The company I was at up to 2010 did not use C++0x features. The company I contracted for back in 2013/2014 did not use C++11 (although we did, in our code). The company I work for now, again, doesn't use C++11 (but hey, we're replacing NULL with nullptr when we come across it). This is not new or strange. Go back 10 years and lots of gamedevs were still avoiding the standard library. Go back 15 years and plenty still viewed C++ with suspicion when C worked perfectly fine. Keeping on top of compiler changes and new language features is low priority relative to (a) successfully shipping games using tech that is already well understood, and (b) keeping up with new tech that can't be safely ignored, such as rendering tech, new input hardware, new consoles, etc. Discussions of new language features have to be made in that context.


I wonder what percentage of new C++ games are being made with exceptions and RTTI turned off.

In Topic: Getting Objects To Not Lose Scope?

17 July 2016 - 03:08 PM

I just want to point out, if you are debugging a problem and a raw pointer is NULL, that doesn't mean the object has been destroyed or has gone out of scope. A pointer to something keeps its value until you overwrite it. It isn't going to change just because the object it's pointing to isn't valid any more. It'll keep pointing to the same memory address.

So, if you're working on a problem and you see a NULL pointer, look for places in your code that modify the pointer itself, not the value it references.

In Topic: Finding that balance between optimization and legibility.

11 July 2016 - 12:20 AM

For me personally (and in my own subjectivity), I've found working within the confines of the C++ and OOP in general to be quite problematic.

You're not transcending the boundaries of C++ and OOP. You're just achieving your goal of caching these numbers with the smallest, easiest edit possible. There's no balance here. There's no actual concern for legibility that I can see.

You're modifying your code in the same way practically every modification is made to so-called OOP C++ programs out there - in whatever way lets the programmer move on to the next task and keep collecting paychecks. Please do not act like this is something special. You are not challenging conventional thinking. You are demonstrating it.

In Topic: Finding that balance between optimization and legibility.

09 July 2016 - 05:19 PM

After crunching some numbers, I calculated that my cache hit was approximately 70%, so I'm thinking about keeping this example in my code for now (if not for the performance gain, then at the very least as a reminder).  


I know some (most) of you are thinking "...and? is that it?", and I get it, this is a very trivial example (some may even argue that the gains are not non-existent), but I feel like it serves as one example (good or bad) of how to code with a particular mindset, expressing awareness of what is exactly is going on in your code, not always keeping a back and white approach to what you are doing, rather be creative and look for the "good enough" approach to problem solving. I also understand that veteran programmers are already doing this on a much greater scale than this, and with greater intuition than I'm exhibiting. Perhaps this example could serve well for beginners, either way I would like to hear what y'all have to say.  

First, how much faster did your program get because of this? That's how you measure performance gain, not cache hits.

Second, no, not many veteran programmers I know appreciate functions that look like they should be pure functions, and unexpectedly read and write from static variables. These "creative" solutions are very annoying when you finally figure out what's causing the rare animation bug in a multi-threaded application. I hope no beginners copy this approach. If you want to make an optimization, hacks like this should be the last resort, ideally only made on a "release" version of your game, not on code you would continue to use in future products. You should be willing to refactor your code and actually change where the function calls are made, if the performance gain is meaningful.