Re: Mathematica to .NET compiler
- To: mathgroup at smc.vnet.net
- Subject: [mg79540] Re: Mathematica to .NET compiler
- From: Jon Harrop <jon at ffconsultancy.com>
- Date: Sat, 28 Jul 2007 05:47:35 -0400 (EDT)
David Bailey wrote: > This is interesting - are you saying that Mathematica could do > everything that it does do significantly faster if it used those > techniques, or would something have to be sacrificed? You can write a program that spots special cases and evaluates them using more efficient techniques quite easily and the overhead is minimal. That doesn't sacrifice anything but it doesn't make "everything" faster, only things that are currently limited by the generic term rewriter in Mathematica. There are other trade-offs that you can choose that will make sacrifices. For example, you might want to change the internal representation of an expression so that sequences are trees rather than arrays. That would make some operations slower (e.g. indexing) but many others asymptotically faster (e.g. concatenation, rewriting, searching) and would consume vastly more memory for long, flat sequences. > Are WRI really ignoring something that could speed up the kernel > substantially? They aren't ignoring it, but they will want an integrated solution that works transparently inside the current Mathematica rather than a compiler that makes it easy for people to migrate away from their platform, of course. > While not exactly disagreeing with you, I suspect there are a lot of > trade-offs here, some of which may be quite subtle. For example, simple > timing experiments seem to indicate that Mathematica can tell very > cheaply (i.e. in a time that does not depend on the complexity of the > expression) when a complicated expression needs re-evaluation - such as > when one of its variables is given a value. Clearly, whatever data > structures they use for this must require CPU cycles to maintain, but > may be extremely valuable in serious algebraic manipulation. In other > words it might be very easy to speed up certain operations while > drastically slowing others. Some changes are a no-brainer, like using a real GC and compiling to native code. Other changes are certainly a trade-off, yes. > Of course, when speed really counts - such as matrix algebra - > Mathematica switches to packed arrays, which can be accessed in a C-like > fashion. Yes, and it implements the most common array-based algorithms as library functions that really are implemented in C. So you can do a cyclic convolution with ListConvolve very efficiently, barely even touching the rewriter. Such situations would be unaffected. However, that is not the only situation "when speed really counts". Plenty of performance-critical Mathematica programs are limited by other bottlenecks. > At a guess, the tree-like structure of Mathematica expressions means > that it is fairly easy for them to avoid cyclic structures. Except that expressions refer to each other and the data then forms a graph, that can easily contain cycles. > Finally, why not target Java? .NET and Java have extremely similar > architectures, and Java operates across all platforms. The main reason is simply that pattern match compilers are already available for .NET (e.g. in F#). There are many other options, like OCaml and Haskell. Another possibility is to target existing symbolic maths packages. > Maybe the way to start on this project would be to pick a range of small > but realistic (un-tweaked) benchmarks and hand-compile them to determine > the speed improvements. I am sure lots of us here would be happy to > supply examples, and discuss the results! It seems to be just you and me. :-) MathCode gave a nice but simple example of computing a big symbolic Hessian in Mathematica and then generating C code to evaluate it: http://library.wolfram.com/infocenter/TechNotes/5998/ The compiler is very limited in terms of functionality but shows up to 1,000x performance improvements over Mathematica on the cases that it can handle. -- Dr Jon D Harrop, Flying Frog Consultancy OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet