Essentially what it says in the title. Mathematica can export its code to C. How much overhead does that inflict on the code, as compared to writing it from scratch in C?

  • $\begingroup$ wow, since when does mathematica does C ? I'm not sure a software like mathematica is made to use C language, is it ? $\endgroup$
    – jokoon
    Commented Jan 28, 2012 at 17:31

4 Answers 4


A lot depends on how you write your code in Mathematica. In my experience, the rule of thumb is that the generated code will be efficient if the code inside Compile more or less resembles the code I would write in plain C (and it is clear why). Idiomatic (high-level) Mathematica code tends to be immutable. At the same time, Compile can handle a number of higher-level functions, such as Transpose, Partition, Map, MapThread, etc. Most of these functions return expressions, and even though these expressions are probably passed to the calling function, they must be created. For example, a call to ReplacePart which replaces a single part in a large array will necessarily lead to copying of that array. Thus, immutability generally implies creating copies.

So, if you write your code in this style and hand it to Compile, you have to keep in mind that lots of small (or large) memory allocations on the heap, and copying of lists (tensors) will be happening. Since this is not apparent for someone who is used to high-level Mathematica programming, the slowdown this may incur may be surprising. See this and this answers for examples of problems coming from many small memory allocations and copying, as well as a speed-up one can get from switching from copying to in-place modifications.

As noted by @acl, one thing worth doing is to set the SystemOptions -> "CompileOptions" as

SetSystemOptions[ "CompileOptions" -> "CompileReportExternal" -> True]

in which case you will get warnings for calling external functions etc.

A good tool to get a "high-level" but precise view on the generated code is the CompilePrint function in the CompiledFunctionTools` package. It allows you to print the pseudocode version of the byte-code instructions generated by Compile. Things to watch for in the printout of CompilePrint function:

  • Calls to CopyTensor
  • Calls to MainEvaluate (callbacks to Mathematica, meaning that something could not be compiled down to C)

One not very widely known technique of writing even large Compile-d functions and combining them from pieces so that there is no performance penalty, is based on inlining. I consider this answer very illustrative in this respect - I actually posted it to showcase the technique. You can also see this answer and a discussion in the comments below, for another example of how this technique may be applied.

In summary - if you want your code to be as fast as possible, think about "critical" places and write those in "low-level" style (loops, assignments, etc) - the more it will resemble C the more chances you have for a speed-up (for an example of a function written in such a style and being consequently very fast, see the seqposC function from this answer). You will have to go against Mathematica ideology and use a lot of in-place modifications. Then your code can be just as fast as hand-written one. Usually, there are just a few places in the program where this matters (inner loops, etc) - in the rest of it you can use higher-level functions as well.

  • 7
    $\begingroup$ it may be worth mentioning that one may do things like SetSystemOptions[ "CompileOptions" -> "CompileReportExternal" -> True] to see some warning of calls to external functions, as well as other options in SystemOptions["CompileOptions"] $\endgroup$
    – acl
    Commented Jan 27, 2012 at 20:53
  • $\begingroup$ @acl Thanks, I incorporated your remark in my answer. $\endgroup$ Commented Jan 27, 2012 at 21:07
  • 1
    $\begingroup$ Also Compile does not work for highly-optimized command as SparseArray, or DiagonalMatrix. I dont think that rewrite SparseArray or DiagonalMatrix in C-style, then Compile to C is more efficient than built-in SparseArray. So sometimes, try to quit the Compile, and use the highly-optimized command. $\endgroup$
    – Nam Nguyen
    Commented Feb 14, 2014 at 18:01
  • $\begingroup$ @DaoTRINH Yes, sure, I agree. I think this discussion was (intentionally) restricted to the subset of Mathematica code / structures, which Compile can handle. $\endgroup$ Commented Feb 14, 2014 at 18:06
  • $\begingroup$ @LeonidShifrin :) Weekend and SE. Do you think that rewrite the Compile could solve these problems to generate more optimized C-like code and get compiled in c compiler? Have you try the MathCode add on ? wolfram.com/products/applications/mathcode $\endgroup$
    – Nam Nguyen
    Commented Feb 14, 2014 at 19:34

In addition to the answers given, you may tweak specific commands to give better performance. For example Part[] is a candidate for this. Part has to do bound checks. In time critical inner loops you can switch that off by using Compiler`GetElement[] instead. Very cautious with this one.

Another thing you might want to try (never needed this myself) is to give platform specific compile optimization options that your CPU supports:

Compiler`$CCompilerOptions = {"SystemCompileOptions" -> "-fPIC -O3"}

I think default optimization is -O2.

Furthermore, for example basic arithmetic operations are quite optimized and linking to the runtime lib should be quite fast.


One important point I forgot, the internal optimizer will find a good way to formulate your expressions

Experimental`OptimizeExpression[{x^2 Sin[x^2]}]

Also, with the symbolic power you can simplify expression you could never do by hand or pen an paper....

To see what can be compiled have a look at:


Find get warning about external symbols not included you can alternatively use:


Also RuntimeAttributes -> Listable provides for very easy parallelization.

  • $\begingroup$ What does -fPIC do? $\endgroup$
    – Szabolcs
    Commented Jan 27, 2012 at 21:26
  • $\begingroup$ @Szabolcs, man gcc is your friend: "Generate position-independent code (PIC) suitable for use in a shared library..." $\endgroup$
    – user21
    Commented Jan 27, 2012 at 21:31
  • $\begingroup$ You showed many interesting things! Is the expression optimizer used by Compile, or is it meant for manual use? Does the Experimental`OptimizedExpression head have any special function, or it could be a simple Hold instead? $\endgroup$
    – Szabolcs
    Commented Jan 27, 2012 at 22:03
  • 3
    $\begingroup$ Another option you might want to pass to gcc is -march=native: That way you allow gcc to use everything the processor on your machine has to offer, at the cost of portability of the compiled code (which in this case you probably won't care about). $\endgroup$
    – celtschk
    Commented Mar 9, 2012 at 12:01
  • 1
    $\begingroup$ Don't know if this were mentioned somewhere but in contrary to Part[] the Compiler`GetElement[] does not work with negative indices. $\endgroup$
    – mmal
    Commented Oct 20, 2015 at 10:05

I don't have an answer but this is a bit hard to format in a comment. If runtime speed is your goal, I'd suggest using Compile with settings

CompilationOptions ->
  {"ExpressionOptimization" -> True, "InlineExternalDefinitions" -> True},
RuntimeOptions -> "Speed"

I'm not certain about the inlining, and there may be other options worth tweaking to get the best speed. Also I would imagine to some extent the speed will depend on the optimization capabilities of the C compiler.

But then, I tend to imagine lots of things.


If you use the setting CompilationTarget -> "C" (documentation: CompilationTarget) you get a function that is literally converted to C code and compiled:

f = Compile[{{x, _Real}}, Sin[x] + x^2 - 1/(1 + x), 
   CompilationTarget -> "C"];

Then you can actually export the C code and look at, or use ExportString to print it directly in Mathematica:

ExportString[f, "C"]

That call to ExportString ends with a function looking something like this:

DLLEXPORT int m-b7accf23-a350-44c5-917c-8adbcacfe423(WolframLibraryData libData, mreal A1, mreal *Res)
mreal R0_0;
mreal R0_1;
mreal R0_2;
mreal R0_3;
mreal R0_4;
R0_0 = A1;
R0_1 = sin(R0_0);
R0_2 = R0_0 * R0_0;
R0_3 = (mreal) I0_0;
R0_3 = R0_3 + R0_0;
R0_4 = 1 / R0_3;
R0_3 = -R0_4;
R0_1 = R0_1 + R0_2 + R0_3;
*Res = R0_1;
funStructCompile->WolframLibraryData_cleanUp(libData, 1);
return 0;

So you can see that with CompilationTarget -> "C" and basic (C-like) arithmetic operations you do get fairly unadulterated C.

  • 1
    $\begingroup$ The function name looks like invalid C. Modern Mathematica versions don't seem to produce such invalid code. $\endgroup$
    – Ruslan
    Commented Feb 7, 2016 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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