Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1999
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1999

[Date Index] [Thread Index] [Author Index]

Search the Archive

RE: Re: Compiling a Module

  • To: mathgroup at smc.vnet.net
  • Subject: [mg15995] RE: [mg15877] Re: Compiling a Module
  • From: "Ersek, Ted R" <ErsekTR at navair.navy.mil>
  • Date: Fri, 19 Feb 1999 03:27:09 -0500
  • Sender: owner-wri-mathgroup at wolfram.com

A member of this group wrote:
>
>Can anyone tell me, why compiling a module saves no time during
>execution?
>

As another member of the group indicated a CompiledFunction doesn't run very
fast if it can't be represented using all op-code instructions.  If you have
a CompiledFunction named (func) you can see if any part of it didn't get
converted to op-code by evaluating func[[3]].  Often times this is much more
concise than FullForm[func]. What you get back will mostly be a list of
lists.  Most of the sub-lists will be vectors of integers.  The parts that
don't make it into op-code look like {31,Function[{x},......]}.  What you
see inside Function will be a part of your program the interpreter has a
problem with.

The function 'CheckCompiled' below takes a CompiledFunction and returns a
list of all the expressions that don't get converted to op-code.  If it
gives you an empty list you have an efficient CompiledFunction.

In[6]:=
CheckCompiled[func_CompiledFunction]:=
  Cases[func[[3]],
    bad_Function:>Extract[bad,2,HoldForm],{2}
  ]

______________________________

Some very helpful info is available at 
http://www.wolfram.com/support/Kernel/Symbols/findsymbol.cgi
This page includes a list of symbols version 3.0 can convert into op-code.

But even if every symbol you use is included on that page your program still
may not convert to op-code.  I hear this can happen for lots of reasons, but
I only know of a few (each discussed below).
 
_____________________
A global variable can't be represented using op-code.  The compiled function
(f2) below isn't converted to op-code because the global variable (w) is
used in the function.  The best way around this that I know is to provide
the global variable to the function as an argument.

In[1]:=
w = 0.25; 

In[2]:=
f2 = Compile[{x}, (x^2 + Sqrt[Exp[x]]+w)];

Evaluate f2[[3]] and you will see the op-code translation of this program.

______________________
You can't use opcode to change the value of a function's argument.  The
CompiledFunction below doesn't convert to op-code because the function
changes the value of (x) (one of the function's arguments).


In[3]:=
f3=Compile[{x,y},
x=Floor[y];
x+y]

_____________________

About a year ago a relatively long program using Compile had the same
problem as the short program below.  The solution with extensive discussion
was provided by Dave Withoff (of Wolfram Research).  The program below isn't
converted to op-code because of the line If[x<0, a=1.0].  When x<0 the If
returns a Real.  When x>=0 the If returns Null (Mathematica jargon for
nothing).  This is unacceptable for the interpreter so it doesn't get
converted to op-code.

In[4]:=
f4=Compile[{x},
Module[{a=2.0},	
 If[x<0,a=1.0];
 x+a]
]

To fix the program above change (a=1.0) to (a=1.0;) as below.  That way the
interpreter knows the If will always return 'Null'.

In[5]:=
(* This will convert to op-code *)
f4=Compile[{x},
Module[{a=2.0},	
 If[x<0,a=1.0;];
 x+a]
]

______________________

Regards,
Ted Ersek


  • Prev by Date: RE: Mathematica vs. Executable code
  • Next by Date: RE: Pure Functions in rules
  • Previous by thread: Re: Compiling a Module
  • Next by thread: graphing inequalities