|
| Re: Best way to inline target-specific code? [message #490742 is a reply to message #490644] |
Sat, 10 October 2009 00:57   |
 Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Brian Cruickshank wrote:
> I am trying to write some platform independent code that can be
> configured to take advantage of some target-specific features when it is
> run on an appropriate target.
> I've looked at the way the xdc.runtime.Timestamp module uses a proxy to
> access target-specific timer values, and noticed that there is a fair
> bit of overhead involved in calling the proxy unless you turn on
> whole_program optimization.
In order to separate the platform-independent code from the platform
dependent code, you need an interface, say Services, which the
platform-independent code can call that's available on all platforms.
There are two "classical" methods for linking the platform-independent
code to the platform-dependent code:
1. the Services interface is defined to be a specific set of
functions with well known names that are directly referenced
from the platform-independent code; e.g., fopen(), fclose() ...
2. Services is defined to be a set of function pointers
the platform-independent code references these functions
through a function pointer that is somehow passed or
"bound" to the platform-independent code.
The advantage of 1. is that the overhead consists of a single function
call whereas going through a function pointer incurs a few instructions
to fetch the function address before making the call.
The advantage of 2. is that you can have multiple platform-dependent
implementations of the _same_ interface in a single application. For
example, you may want to have multiple implementations of a memory
manager, or a timer, or .... By going through a function pointer, the
platform-independent code can be bound to any of several possible
implementations without restricting the use of other implementations in
the rest of the application.
The proxy-delagate pattern is specifically designed to support 2. _and_
enable whole-program optimizers to "see" that the platform-specific
code can be in-lined into platform-independent code bases resulting in a
zero overhead implementation. Tastes great _and_ less filling!
That said, if you use proxy-delegate without whole-program optimization,
you will pay the price of the extra load of the function pointer before
the call. Note that without whole-program optimization, however, you
_always_ pay the cost of the function call. So, the cost of
proxy-delegate is really just the incremental cost of an indirect call
over a direct function call.
> Is there a way to either use a macro to implement the proxy or to tell
> the compiler to always inline such code in order to avoid the overhead
> associated with calling the proxy method?
|
|
|
| Re: Best way to inline target-specific code? [message #490774 is a reply to message #490742] |
Sat, 10 October 2009 14:41 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
I responded too quickly and need to correct myself below.
dave russo wrote:
>
>
> Brian Cruickshank wrote:
>> I am trying to write some platform independent code that can be
>> configured to take advantage of some target-specific features when it
[snip]
>
> The proxy-delagate pattern is specifically designed to support 2. _and_
> enable whole-program optimizers to "see" that the platform-specific
> code can be in-lined into platform-independent code bases resulting in a
> zero overhead implementation. Tastes great _and_ less filling!
>
While proxy-delegate does support 2., it does _not_ use function
pointers. The use of function pointers defeats whole-program optimizers
due to pointer aliasing; the compiler almost never knows that the
pointer always points to a specific function and, as a result, can't
inline the function pointed to.
> That said, if you use proxy-delegate without whole-program optimization,
> you will pay the price of the extra load of the function pointer before
> the call. Note that without whole-program optimization, however, you
> _always_ pay the cost of the function call. So, the cost of
> proxy-delegate is really just the incremental cost of an indirect call
> over a direct function call.
>
Here is the mistake. Proxy-delegate can't use the classic vtables
because of the aliasing problem, so the incremental cost without whole
program optimization is higher than the difference between a direct call
and an indirect call.
Proxy-delegate works by generating a function stub that is directly
called by the referencing client (the platform independent code). The
stub then directly calls the delegate. Since this stub and the caller
both use direct calls, the compiler never looses sight of the final
callee (the delegate) through a pointer and can directly in-line the
delegate into the caller.
So ... the incremental overhead of proxy-delegate is one more function call.
>> Is there a way to either use a macro to implement the proxy or to tell
>> the compiler to always inline such code in order to avoid the overhead
>> associated with calling the proxy method?
|
|
|
Powered by
FUDForum. Page generated in 0.02399 seconds
] 
Search
Help
Register
Login
Home
