Re: Mathematica to .NET compiler
- To: mathgroup at smc.vnet.net
- Subject: [mg79340] Re: Mathematica to .NET compiler
- From: Jon Harrop <jon at ffconsultancy.com>
- Date: Wed, 25 Jul 2007 02:04:50 -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 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.
If you target an existing compiled, high-level language then it is quite
easy to beat the performance of the current Mathematica implementation in
this area. For example, there is a great deal of published research on
pattern matching for high performance languages like OCaml. This is an
untapped resource when it comes to Mathematica.
There are many other compiler technologies of enormous practical relevance,
such as type inference. I believe the MathCode compilers can handle:
average[a_Real, b_Real] := (a+b)/2.
but not:
average[a_, b_] := (a+b)/2.
or:
average[{a_Real, b_Real}] := (a+b)/2.
or:
average[a_Real] := a
average[a_Real, b_Real] := (a+b)/2.
for example. I doubt any real Mathematica code is written in that style so
users will have to manually add type annotations throughout their code
before it will compile. As the compiler doesn't support destructuring of
nested lists using pattern matching, most APIs will probably have to be
changed by hand as well.
> 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 can see no way to help them. Implementing the sophisticated functionality
in Mathematica's standard library is a prohibitively complicated
undertaking and, even if you could do it, Wolfram Research would prohibit
dissemination of the result in any form.
So users would still need to use a copy of Mathematica to do symbolic
computation using that kind of sophisticated functionality.
I am essentially advocating a better version of Compile. I have found
Compile to be enormously helpful in optimizing Mathematica code but it
supports few programming constructs: cannot handle recursion, pattern
matching and so forth. If users could compile their Mathematica to
stand-alone code written in other languages, such as F#, they would be able
to benefit from high-quality optimizing compilers, better interoperability
and much better performance.
This is essentially a way to address the problem that many users overuse
Mathematica because it has such an alluring development environment but,
ultimately, its language is not well suited to large, long-term code bases
or high performance general computing.
Transitioning Mathematica code to a modern high-performance compiled
language is currently very tedious and error prone. A compiler such as the
one I am advocating would automate this translation, providing users with
an incremental path to more appropriate languages for the parts of their
Mathematica code base that have grown out of control or that have become
performance limited by Mathematica's generic rewriter.
--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet