Thread: Efficiently access member variables

If I have a function that needs very fast (down to instructions level) access to a few variables in a struct, how should I do it?

The program in question is an interpreting emulator. The fetch/decode/execute function needs very fast access to the (emulated) registers.

The logically correct way to do this would be to use a context struct (C style) or have them as member variables and function (C++ style).

Code:

struct Context {
     int regs[16];
}

void f(Context *ctx)
{
     // do stuff with ctx->regs[]
}
...
Then

Context ctx;
f(&ctx);

However, that means all accesses to regs need to go through at least a layer of redirection (de-referencing ctx).

Or in C++

Code:

class C
{
     int regs[16];
     ...
     void f()
     {
          // do things with regs[]
     }
};

which will compile to exactly the same thing (except ctx would be called "this").

A more efficient way is to make them static

Code:

void f()
{
     static int regs[16];
     // do things with regs[]
}

This way would save a de-reference.

However, that's ugly. Is there a way to get best of both worlds? Somehow "instantiating" code?

I'm not sure how well it will perform in comparison, but you can try offsetof(3): offset of structure member - Linux man page .

In the case of C++, then ctx.f() is (usually?) an inline function when f() is a small function declared within the class itself.

Also, if your array subscripts are constants, there is no additional run-time overhead compared to accessing named variables, since the compiler will do all the address calculation at compile time.

That's true, but it seems like inlining won't get rid of the dereferencing by itself. The subscripts are not always constants. Since it's a RISC arch, almost all instructions work on all registers. Though I suppose that's a possible area of optimization.

I'm not sure how well it will perform in comparison, but you can try offsetof(3): offset of structure member - Linux man page .

I believe that's what the compiler will do either way.

I don't think there is any way to reasonably save the dereference. If you make them static data, then you instantly lock yourself in to a single-threaded emulator. It just seems like the wrong design.

Put trust in the compiler. After inlining, cross-module optimizations etc, you may find that the context pointer gets placed directly in a (real) register and lives there for a long time, pretty much wiping out the cost of that dereference.

Yeah I really don't want to go down the static route. I guess that makes sense. LTO + inlining will probably have the pointer end up in a register.

I think I'll just leave it there for now, and see what happens. Speed may not be a problem at all anyways, since I'm only trying to emulate an ARM core at 16.8MHz (GameBoy Advance), so I still have about 100 host cycles to 1 emulated cycle, which should be enough.

Since inlining is simply a suggestion to the compiler I would check the assembly language that is created from your code to ensure it actually did inline them...that is if performance is super critical. If not then I wouldn't go through the trouble. Often times I have been surprised by the un-optimized nature of some assembly output (at least from MSVS) even with all the doo-dads and optimizations turned on.

Be aware of the flaky and often bizarre support for `restrict' or `__restrict__'.

That is one of things that should absolutely be used through macro.

Soma