More power to the C++ gurus

I’ve seen some discussions lately on the web about POD types in C++. These are classes without complicated constructors, assignment operators, etc and are extremely useful for defining things like vectors (float vectors, not the standard library list).

Trouble is, in games your expert programmer will define the vector in the most efficient POD way and everything will run well. That is until someone less obsessed with the low-level details of C++ comes along, flips to the appropriate page of their object oriented programming book, and adds a complex constructor to the class. Everything will continue to work but there’s a very good chance that programmer just wreaked havoc on the frame-rate.

So, here’s what i’m proposing. I want an attribute, just like the __attribute__ extension GCC already has which says “this is a POD class so don’t let anyone add anything to it that stops it being POD”. Note, i don’t want the attribute to make the class POD, its already POD by design. I want the attribute to enforce that property to stop anyone doing anything unwanted thats allowed by the language, but will make the engine gurus angry.

Anyway, just an idea, but one that I think could really be valuable. I’ve also been thinking that a command line option to ban calling virtual functions or malloc from an __attribute__((hot)) function would be nice, or maybe a new attribute that means “so hot you can’t call virtuals from in here”.

Also, just realised the POD attribute isn’t strictly necessary as you could define a union containing an element of the class and comment next to it to say that the union is guaranteeing the POD-ness of the class, but I still like the idea of having more attributes to control allowed code (and give error messages when the rules are broken), and not just hint things to the compiler as most current attributes do.

Advertisements
This entry was posted in C++, Compilers and tagged . Bookmark the permalink.

5 Responses to More power to the C++ gurus

  1. Jedd says:

    With GCC you could place a static assert on __is_pod(class_name) right after the class/struct definition. It wouldn’t too much more verbose than attribute.

  2. Jonathan says:

    Virtual function and malloc() calls aren’t the problem – they’re a symptom of the problem. Even if you could ban them in a particular piece of code, there is an infinite number of other ways an ingenious miscreant programmer can ruin performance.

    To be just a little controversial: with a small enough working set, a large enough cache and a large enough workload, virtual function calls aren’t the YOU SHOT MY I$ disaster that they might otherwise be.

    It all depends on context. __attribute__((hot)) is a hint to the compiler, but the benefit depends on context that is (probably) beyond the compiler to analyse. A function can be meaningfully “hot” and also not meaningfully impacted by virtual function or malloc() calls. How hot is hot anyway?

    I don’t think you can stop people making stupid performance mistakes in code by constraining the tools they may use. What needs to happen is that changes in performance are exposed quickly, and that cause and effect are clearly tied together. Where possible, incremental changes, fast iteration, good profiling and meaningful feedback (“If the frame goes over 33ms, I will hurt you”) are better things to consider.

    Even a static assert (and you can’t have too many static asserts) aren’t going to save you – they are vulnerable to a simple // 🙂

    • petecubano says:

      Yeah, performance of virtuals is all about how they’re used, but i’m sure there’s still some places where a hot attribute banning them could be helpful.

      As for how hot is hot. The coolest thing would be for a tuner to populate that kind of information for you, but thats not something that it would always get right.

      Unfortunately nothing we can do about //, other than severe punishment for its misuse 🙂 But, like you, i do love static asserts

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s