Re: Primitive.IntInf.make

On Wed, Dec 4, 2013 at 4:12 PM, René Neumann <[email protected]> wrote:
> when profiling my application (built with -default-type intinf), I
> noticed that (according to it) ~30% of the time is spent by
> Primitive.IntInf.make.
>
> Is it called on construction of each IntInf? Or only on those that do
> not fit into 32/64bit? Or does this come from somewhere else?

You'll want to use "mlprof -show-line true" to see precisely which
"Primitive.IntInf.make" function is being called; it should be one in
the "$(SML_LIB)/basis/integer/int-inf0.sml" file
(https://github.com/MLton/mlton/blob/master/basis-library/integer/int-inf0.sml).

There are two aspects of the profiling infrastructure that seem to be
conspiring here to confuse the profiling output.

The first aspect is that (by default), the Basis Library
implementation details are excluded from the "local control stack" for
the purposes of profile sampling (see
http://mlton.org/HowProfilingWorks).  You can think of this as follows
(for time profiling): when the profiling timer triggers, if the
current program point is inside the Basis Library implementation, then
walk the stack to find the outermost Basis Library implementation
call.  The point is that the user will find "List.foldl" more helpful
than the internal "loop" function with which "List.foldl" is
implemented.

The second aspect is that the compiler is careful to tail-calls are
not inhibited by profiling data.  Unfortunately, this has a funny
interaction with the previous aspect.  When a Basis Library function
is implemented as a simple tail-call to a helper/utility function,
then we won't have that Basis Library function on the stack to
discover when we walk to find the outermost Basis Library
implementation call; instead, we'll see the helper/utility function as
the outmost Basis Library implementation call.

In your case, there are a few different "Primitive.IntInf.make"
helper/utility functions; most of them are higher-order functions that
assist in dispatching to either the "small" function for operands that
fit into 32/64bit or to the "large" function for operands that don't
fit into 32/64bit.  In particular, all of
IntInf.{+,-,*,compare,<,<=,>,>=,andb,orb,xorb} are implemented by
tail-calling a "make" helper/utility function.

So, I suspect that in your application, the ~30% is being spent in one
of the arithmetic functions.  You could try compiling with
"-profile-include '.*'", which will override the exclusion of the
Basis Library implementation details.  But, that may only help narrow
things down if the expensive operation is for "large" operands; if the
expensive operation is for "small" operands, then the ~30% may, in
fact, be the overhead of untagging and tagging the small operands.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk