When compiling code to C, and the compiled code calls other compiled functions, I see CompiledFunctionCall in the output of CompilePrint most of the time. But sometimes, it's replaced by LibraryFunction[<>,...]. Could anybody explain the difference between these two?

EDIT: As an example, I would expect a LibraryFunction call in the following case. If I define:


If I then define the following:

CompilationOptions->{"InlineExternalDefinitions" -> True,

I see CompiledFunctionCall in the output of CompilePrint[compsum].


It appears that LibraryFunction occurs if the function being called inside the other compiled function is a function that has been compiled to C, provided this function has been called with the right type of arguments. It seems that in other cases there is a CompiledFunctionCall.

As pointed out by Simon Woods in the comments below, there is a type mismatch in the example that you added later, so that in this case CompiledFunctionCall is used.

Be warned that this is based on very few examples, so this may not be the correct explanation.

Here is a simple example where compiled functions are called with the right type of arguments. First we compile it to the WVM and then to C and observe the difference.

<< CompiledFunctionTools`
cf = Compile[{{x}}, Sin[x]];
cf5 = Compile[{{x}}, cf[x^2], 
   CompilationOptions -> {"InlineExternalDefinitions" -> True, 
     "InlineCompiledFunctions" -> False}];
cf5 // CompilePrint
R2 = CompiledFunctionCall[ Hold[CompiledFunction[{x}, Sin[x], \
-CompiledCode-]][ R1]]
cf2 = Compile[{{x}}, Sin[x], CompilationTarget -> "C"];
cf6 =
  Compile[{{x}}, cf2[x^2],
   CompilationOptions ->
    {"InlineExternalDefinitions" -> True, 
     "InlineCompiledFunctions" -> False}
cf6 // CompilePrint
R2 = LibraryFunction[<>, compiledFunction12, {{Real, 0, Constant}}, \
Real][ R1]]

About LibraryFunction

In a compiled function that has been compiled to C, a LibraryFunction will do all the work. A library function is a function that is part of a dynamically linked library that is loaded into the kernel. The dynamically linked library is the result of compiling C code.

The following code creates an expression with head LibraryFunction. It does this by loading a pre-compiled function from a library.

fun = LibraryFunctionLoad["demo", "demo_I_I", {Integer}, Integer];

You can also see a LibraryFunction in the definition of cf2

CompiledFunction[{10, 10.1, 
  5468}, {_Real}, {{3, 0, 0}, {3, 0, 1}}, {}, {0, 0, 2, 0, 0}, 
  {{40, 1, 3, 0, 0, 3, 0, 1}, {1}}, Function[{x}, Sin[x]], Evaluate, 
    {{Real, 0, "Constant"}}, Real]]

In the definition of cf, no such LibraryFunction is present.

Skipping interaction with the CompiledFunction

The compilation process in Mathematica is smart enough to figure out that a compiled function is compiled to C, so it knows that it can simply call the LibraryFunction, rather than interacting with some CompiledFunction object. In fact we can do the same manually. Let

libFunc = cf2[[9]]
LibraryFunction[Function name: compiledFunction12 Argument count: 1]

So that we have defined libFunc as the LibraryFunction that does all the work for cf2.

Then we can do



My guess is that this explains the difference. When calling a function that has been compiled to the WVM, a CompiledFunction is really called. When using a function that has been compiled to C, in the absence of a type mismatch,a shortcut is taken and the LibraryFunction is called directly.

  • 1
    $\begingroup$ Thanks for a nice answer! I must have forgotten to compile the inner function to C in some cases, that's why I sometimes got CompiledFunctionCall. $\endgroup$ – Marius Ladegård Meyer May 9 '15 at 15:35
  • $\begingroup$ Please see my updated question, I think I have found an exception to your answer. $\endgroup$ – Marius Ladegård Meyer May 11 '15 at 7:35
  • $\begingroup$ @MariusLadegårdMeyer good example! I can only guess why it it uses a CompiledFunctionCall here. Perhaps the compiler doesn't care about the additional overhead, because the body of the compiled function is relatively large compared to this overhead. Or the compiler somehow cannot figure out it can use the shortcut. I suppose I should edit my answer slightly, thank you. $\endgroup$ – Jacob Akkerboom May 11 '15 at 9:51
  • 2
    $\begingroup$ @MariusLadegårdMeyer, in your question you are defining compBinomial to take real arguments but when you call it from within compsum you pass integer arguments. I think this type inconsistency is why the library function is not used. $\endgroup$ – Simon Woods May 11 '15 at 19:59
  • $\begingroup$ That seems to have solved it, thanks! @JacobAkkerboom, could you add this info to your answer? $\endgroup$ – Marius Ladegård Meyer May 12 '15 at 6:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.