🚀 go-pugleaf

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 

Fred Ma <fma@doe.carleton.ca> wrote in message 
> 
> Yes, I was thinking of PIC and shared libraries as synonymous,
> even though I am told that they are not.  I'm not too interested in
> their differences, I was just curious about whether my code will
> run any slower when compiled via the mex way, but I'll find out
> once I've finished recoding (getting familiar with passing/returning
> structs and extracting parameters, changing all references to
> cout and cerr to use matlab printing functions, changing all
> exit(EXIT_FAILURES) to throws that are caught by my toplevel
> function, etc..).  I was hoping to get an idea of whether the interfacing
> was all worth it, since my matlab modules only do graphing to
> monitor progress, and digesting results returned by many runs of
> my C++ number cruncher.  Responses in the other newsgroups
> seem to indicate that PIC doesn't adversely affect speed.
> 
> Fred