svn commit: r266974 - in head/sys: dev/dc dev/fxp dev/mii dev/netmap kern net

[Bruce Evans]

On Mon, 2 Jun 2014, Ian Lepore wrote:

> On Mon, 2014-06-02 at 11:42 -0700, Marcel Moolenaar wrote:
>> On Jun 2, 2014, at 11:27 AM, Adrian Chadd <adrian at freebsd.org> wrote:
>>
>>> .. and actually, bikeshedding for a moment, would we be able to move a
>>> lot of these accessor methods over to inlines? Would that break the
>>> Juniper way of doing things?
>>
>> That would definitely break Juniper as it doesn't give a stable
>> ABI.
>>
>> I've suggested an approach that allows for both, but it was deemed
>> unnecessary. The argument being that the function call overhead is
>> negligible.
>>
>> We can always revisit that decision if needed...

I thought it was obviously necessary.  Juniper gets the stable ABI and
slowness, while the default is to have the same code as before, except
it is obfuscated by macros or inline functions.

> In my experience, function call overhead is anything but minimal,
> especially on ARM platforms.

This is of course machine-dependent.  It is not very large on modern
x86.  It was large on old x86.  I think it needs mainly deep pipelines
and out of order execution to be fase.

Testing on old Athlon64 showed that the overhead is quite large even
on modern x86.  Direct accesses to a memory variable can be done at 2
per cycle in a 4-way unrolled loop, but the best I could find for
accessor(&var) in a function call was 1 per 8 cycles, with unrolling
making the accesses slower.  16 times slower.  The unrolled loop is
favourable to the simple operation of a memory load or store of a
single memory (in-cache) variable, but also to calling a single
accessor function.

Bruce