12
$\begingroup$

Bug introduced in 10.4 and fixed in 11.0

After updating to 10.4, many of my heavily numerical functions defined by Compile takes a huge amount of time to compile to Wolfram Virtual Machine.

As an example, after running the definitions in this question to compute the dilogarithm function, observe how long it takes to compile the following function in Mathematica 10.4, and in previous versions (10.3 and earlier):

f = Compile[{{x, _Real}, {a, _Real}, {b, _Real}, {c, _Real}}, 
   reLi2[((x - b^2 + a^2) (a^2 - c^2))/(x a^2 - (b^2 - a^2) (a^2 - c^2))] - 
   reLi2[-(((b^2 - a^2) (a^2 - c^2))/(x a^2 - (b^2 - a^2) (a^2 - c^2)))] + 
   reLi2[-(((b^2 - a^2) a^2)/(x a^2 - (b^2 - a^2) (a^2 - c^2)))] - 
   reLi2[-((a^2 a^2)/(x a^2 - (b^2 - a^2) (a^2 - c^2)))] + 
   reLi2[((x - a^2 + c^2) (c^2 - b^2))/(x c^2 - (a^2 - c^2) (c^2 - b^2))] - 
   reLi2[-(((a^2 - c^2) (c^2 - b^2))/(x c^2 - (a^2 - c^2) (c^2 - b^2)))] + 
   reLi2[-(((a^2 - c^2) c^2)/(x c^2 - (a^2 - c^2) (c^2 - b^2)))] - 
   reLi2[-((c^2 c^2)/(x c^2 - (a^2 - c^2) (c^2 - b^2)))] - 
   reLi2[((x - (a^2)^2 + (c^2)^2) ((c^2)^2 - (b^2)^2))/(x (c^2)^2 - ((a^2)^2 - (c^2)^2) ((c^2)^2 - (b^2)^2))] - 
   reLi2[-((((a^2)^2 - (c^2)^2) ((c^2)^2 - (b^2)^2))/(x (c^2)^2 - ((a^2)^2 - (c^2)^2) ((c^2)^2 - (b^2)^2)))] + 
   reLi2[-((((a^2)^2 - (c^2)^2) (c^2)^2)/(x (c^2)^2 - ((a^2)^2 - (c^2)^2) ((c^2)^2 - (b^2)^2)))] - 
   reLi2[-(((c^2)^2 (c^2)^2)/(x (c^2)^2 - ((a^2)^2 - (c^2)^2) ((c^2)^2 - (b^2)^2)))], 
 CompilationOptions -> {"InlineExternalDefinitions" -> True}]

My MacOS X 10.10$^†$ computer takes 3 seconds on Mathematica 10.4, and nearly instantaneous on Mathematica 9.0.1. The actual functions used in my code contains over 100 instances of reLi2 in the body of Compile, and it takes over a minute just to compile on version 10.4.

Does anyone else observe this problem? Are there any workarounds? Setting option "ExpressionOptimization"->False helps just a tad, but not nearly enough.

$^†$ update: I also observe the problem in Linux.

Improve this question
$\endgroup$
9
  • 1
    $\begingroup$ Something spooky: when you put semicolon ; at end of the command to "suppress the output" compilation goes quickly like in earlier versions. This semicolon trick does not work if this code is called from a package file. $\endgroup$
    – QuantumDot
    Mar 17, 2016 at 18:58
  • 1
    $\begingroup$ It looks like it's the typesetting that takes all the time. Try using SetSystemOptions["TypesetOptions" -> {"IconicElidedForms" -> False}] $\endgroup$
    – Simon Woods
    Mar 17, 2016 at 21:54
  • $\begingroup$ @SimonWoods Thanks, this seems to solve some of the cases, but not all. In particular, if the body of the Compile is constructed using With for code injection, it still performs much slower than earlier versions. $\endgroup$
    – QuantumDot
    Mar 18, 2016 at 8:18
  • $\begingroup$ This problem has been reported [CASE:3559742]. $\endgroup$
    – QuantumDot
    Mar 18, 2016 at 21:01
  • 1
    $\begingroup$ @QuantumDot I have forwarded your contact details to our prerelease program coordinators and I hope they will be in touch soon with more information. $\endgroup$
    – ilian
    Jun 4, 2016 at 15:52

2 Answers 2

Reset to default
5
$\begingroup$

That 3 seconds in 10.4 is an improvement over 5.3 s in 10.3. :)

I can't imagine any scenario where how you construct the function affects its formatting (assuming you're creating the same). I guess the fact that it isn't helped by disabling iconic elided forms suggests the issue is elsewhere. Also, does disabling the outuput (using a semi-colon) still result in a slowdown? That means the slowdown is either in evaluation or in the transmission over MathLink to the kernel. If you have a concrete example, that would be helpful.

The new iconic forms were made interpretable, meaning if you copy an output into an input cell (or hit Cmd/Ctrl-Shift-L), it will parse and evaluate correctly. This means the formatted forms are much larger in size, since they contain complete info for reconstructing the CompiledFunction, and hence notebooks containing them in output will be much larger. So you have a lot of these in output cells, you'll have much bigger notebooks. You might want to disable the icon forms or suppress output to save space (and the time saving the notebook) in addition to the speed up from not formatting them.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I have reported this problem [CASE:3559742], and have notified technical support that the problem is urgent because compilation time in my package is now over 90 seconds with v10.4, when it was well under 1 second in v10.3 and earlier. While evaluation speeds of Compile called directly within the notebook can be improved with a semicolon or by modifying SystemOptions, nothing seems to be possible to improve compilation times from within a package file. $\endgroup$
    – QuantumDot
    Mar 18, 2016 at 20:59
  • $\begingroup$ You are confusing 2 issues. An input is first evaluated and then--if displayed--formatted. A Compile in a notebbok and in a package file evaluate in the same amount of time. If you allow it to format, that formatting takes a certain amount of time--but Get doesn't output a result to be formatted. Formatting CompileFunction takes longer in 10.x than 9, which is addressed by the SystemOption or suppressing output. Your particular compile statement exhibits a new in 10.4 slowdown during evaluation itself. This seems to be an unexpected change from a bugfix, but is still under investigation. $\endgroup$
    – Itai Seggev
    Mar 19, 2016 at 0:49
  • $\begingroup$ Thanks for the clarification. I wait anxiously for a fix/workaround. $\endgroup$
    – QuantumDot
    Mar 19, 2016 at 8:23
2
$\begingroup$

As of version 11, the bug has been fixed. Compile now performs like it did in version 10.3 and earlier.

Improve this answer
$\endgroup$

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.