On 03/04/2012, at 5:00 PM, Doug Baskins wrote:
> Gang:
>
> On modern processors, the problem of branch prediction is more
> important than subroutine call/returns, so inline code is not where
> your focus should be. Subroutine call/returns are fully predictable
> whereas a simple if <condition> statement is NOT. I have found
> that inlining only helps on the most trivial piece of code (on Intel 386 etc)
> and the compiler does a good job on doing it for you. MACRO's
> are a waste of time, IF used for improving performance. I now use
> them only to abbreviate/document trivial things or to make simple changes
> to test code in a 1000 places.
This is not quite true. Generally small subroutine calls are
reasonably fast, and inlining may not appear to save much.
However, the implicit assumption that overhead is in
JSR/RET instructions and not other things is false in general.
For small flaf leaf routines where the register allocation model allows
a subroutine call with zero parameter passing overhead,
then sure, the JSR/RET cost is minimal.
But this is a pretty low level "macro vs inline subroutine" comparison.
For "real code" the difference is utterly profound and it is the ONLY
thing of any significance. Inlining does a lot more than save a
JSR/RET. It saves copying arguments. It saves evaluating
arguments. It saves stack space. It allows a major collection
of optimisations that would not be possible otherwise.
In Felix the difference between "standard model" functions
(which are C++ class objects) and inlined code is something
like 1000 times.
The class objects, methods, etc are too hard for stupid compilers
to optimise. But after inlinling an addition function taking arguments
"a" and "b" to
a + b
gcc does a reasonable job adding them quickly .. :)
--
john skaller
[email protected]
http://felix-lang.org
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
