I'm speaking in general terms, but, yes, simple accessors can definitely be a problem depending how the program is structured. I've seen many a game engine written in C++ with full encapsulation where a statistical profile shows nearly all of the time in the prolog and epilog. The actual accessor doesn't cost anything (maybe 1-2 instructions), but the setup for the stack frame kills it. A stack frame setup forces accesses to memory so even though the number of instructions is small, the impact on the performance is significant. Having the instructions sit in the icache does help in terms of instruction fetch times, but the data operations involve a read-modify- write pattern which won't sit well in many cache structures.

To be entirely fair, this problem with accessors mainly shows up when there are a large number of instances of the object and the accessor is being called as part of a traversal over the instances.

The typical solution is to allow direct access to the data member to avoid the stack frame setup/teardown overhead.
--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split it with him."
 -- Unsigned



On Jun 2, 2009, at 3:26 AM, Duane Ellis wrote:

You don't want to waste a lot of time in simple accessors if they are called frequently enough

Really? Sure - a few opcodes ... but in the grand scheme of things...
For example the function target_write_memory() - with "-O2" is exactly these instructions

        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %edx
        popl    %ebp
        movl    (%edx), %ecx
        movl    64(%ecx), %ecx
        jmp     *%ecx

(A) 7 instructions, operating at 1ghz.

(B) if they are called "frequently enough" they live in the cache and are faster!

(C) And because the code is "more common/reused" - identical 7 instruction sequences in multiple places do not cause other identical 7 instruction sequences (at another address) to leave the cache

The same argument can, to a degree, be made *against* 'static inline' functions in headers.

-Duane.




Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to