Re: Mathematica to .NET compiler
- To: mathgroup at smc.vnet.net
- Subject: [mg79359] Re: Mathematica to .NET compiler
- From: David Bailey <dave at Remove_Thisdbailey.co.uk>
- Date: Wed, 25 Jul 2007 02:14:56 -0400 (EDT)
- References: <f7pon7$prc$1@smc.vnet.net><f7sgu2$ss8$1@smc.vnet.net> <f84juv$qpq$1@smc.vnet.net>
vengelson at gmail.com wrote: > The compilable subset of MathCode is now available again at > > http://www.mathcore.com/products/mathcode/subset.php > > As you might notice it includes mostly numerical functions of > numerical (+complex) arguments, as well as > multidimensional rectangular array handling. There are some tricks to > handle other functions, explained in the manual. > > The main problem with Mathematica compilers is not target code > generation. > Whatever target code can be easily generated, either C++ or Fortran or > Java or C# or even bytecode. > Since users would perfer high performance, source code portability and > code readability, > C++ becomes at least a rather good choice. MathCode for Java was just > another back-end, it > was under development some time ago but it was frozen because of lack > of interest. > > The main problem with Mathematica compilers is not the basic kernel. > Dynamic symbol tables, sparse arrays, tree data structures are known > for many years. Well, it can be relatively tricky > to make their performance optimal, and this is one of reasons why they > are missing in MathCode for the moment. > > The main problem is reliable reimplementation of "heavy" features like > symbolic integration, Simpify[] or NDSolve[]. There is lot of > knowledge and tons of heuristics inside. > I believe, most people would like to have these features, > with the source code and without Mathematica beeing installed on > target machine. > How would you help them ? > > > I would think there are two kinds of potential use here. If you are compiling Mathematica code in order to run it without the use of Mathematica then everything a user will need - such as NDSolve - would need to be supplied. Ultimately this would involve the re-implementation of the entire Mathematica kernel! On the other hand, there may be users that would like to compile code that would be started from Mathematica and use the kernel to perform operations that cannot be compiled. For this use, Java would be a good target language since it works cross-platform and is always available with Mathematica. If the compiler produced CLASS files (rather than Java source) it would integrate with Mathematica rather neatly. With modern JIT Java implementations, the speed of Java code can comparable with C, provided new objects are only created infrequently. However, as I see it, care would have to be taken to ensure that the costs of inter-process calls did not more than cancel any gains obtained by compilation in an environment in which Mathematica still performed part of the work. This can be hard for a compiler to determine. For example, imagine two 'heavy' operations either side of a matrix operation that could be efficiently compiled. The compiler may not 'know' the size of the matrices that will be used - if eventually the matrices turn out to be 3x3, the gain would probably be swamped by the cost of the process switches, if the matrices turn out to be of size 500x500, the compiled code should operate much faster. David Bailey http://www.dbaileyconsultancy.co.uk
- Follow-Ups:
- Cyclic permutations
- From: "King, Peter R" <peter.king@imperial.ac.uk>
- Cyclic permutations