🚀 go-pugleaf

Bart Smaalders wrote:

> Typically, the performance overheads associated with PIC
> code will manifest itself in the following areas (on SPARC):
>
> 1) The increased number of instructions can be seen
>    in very simple programs that fit in I & D caches
>    since E$ and memory latencies don't hide anything.
>
> 2) Very simple leaf routines that access global data will
>    now require a register window as a result of how they
>    find the GOT (global offset table).  This can increase
>    register window spill fill traps in some cases; typically
>    seen with C++ "data hiding" functions that insist on
>    using global flags to control their behavior. If the data
>    objects being used are large, including a pointer to a structure
>    containing important global state can significantly improve
>    performance of trivial functions.  In C:
>
>    Rather than
>
>    int
>    get_count(myobj_t * foo)
>    {
>          if (debug_flag) {
>                  ...
>          }
>          return (foo->count);
>    }
>
>    add a pointer to myobj_t to point to global state and get
>
>    int
>    get_count(myobj_t * foo)
>    {
>          if (foo->global_data->debug_flag) {
>                  ...
>          }
>          return (foo->count);
>    }
>
>    Where possible, one can of course inline the accessor functions,
>    but this eliminates some of the advantages of using them in the
>    first place.
>
> 3) In PIC code, all calls to non-local functions must be done
>    through a PLT (procedure linkage table), as the address of
>    the target function is not known at compile time.  These PLT entries
>    initially point into the dynamic linker, and are then resolved
>    the first time they're called and the code in the PLT is updated
>    to call the function directly.  However, calling global functions
>    outside the shared library will always involve 2 function calls,
>    so we end up w/ a few more cycles _and_ more itlb pressure.
>    Note that we can optimize the number of global symbols by scoping
>    the library so that only externally used symbols remain global
>    (see Linker and Library Manual at http://docs.sun.com).  If you're
>    not interposing on symbols in the library, the library may also be
>    linked w/ -Bsymbolic, although this can cause problems w/ some C++
>    environments (sigh)).
>
> In most cases, these effects are not significant. Sometimes, however,
> they can cause a lot of head scratching.
>
> - Bart

Hi, Bart,

A lot of that went over my head.  But I appreciate the time you
took to explain it. I ran a test case on an older version of my
program (non of the PIC/shared compilation to link to matlab),
and it rand about 20% faster.  But that could be due to a very
arduous parameter passing protocol I use to check any
data passed from matlab.  For each argument, I do a brute
force comparison with all simulation parameter names to see
if it is a valid parameter specification, and checking types and
array sizes on top of that.  I will do something smarter, like
STL's map container, at a later time.

Fred