Re: Mathematica to .NET compiler
- To: mathgroup at smc.vnet.net
- Subject: [mg79463] Re: Mathematica to .NET compiler
- From: David Bailey <dave at Remove_Thisdbailey.co.uk>
- Date: Fri, 27 Jul 2007 05:53:49 -0400 (EDT)
- References: <200707200725.DAA24728@smc.vnet.net> <f7sflm$rs0$1@smc.vnet.net> <f86onh$g19$1@smc.vnet.net> <f89p6l$54l$1@smc.vnet.net> <f89t3u$9es$1@smc.vnet.net>
Jon Harrop wrote: > David Bailey wrote: >> Surely to support all those features you would need to write something >> equivalent to a fair portion of the Mathematica kernel - why would your >> code work any faster than Wolfram's? > > Garbage collection for one thing. The real Mathematica uses reference > counting, which is widely known to be both flawed (can't collect cycles) > and slow (was dismissed as a competitive technique decades ago). Inheriting > a garbage collector from something like .NET lets you replace a core > component of Mathematica with a piece of code funded by the world's > wealthiest software company, written by dozens of experts over many years > with enormous emphasis on performance. > > Type inference for another thing. This technique is widely used in modern > high-performance functional programming languages to combine the brevity of > Mathematica with the speed of C++. The current Mathematica does no type > inference. > 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? Are WRI really ignoring something that could speed up the kernel substantially? 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. Of course, when speed really counts - such as matrix algebra - Mathematica switches to packed arrays, which can be accessed in a C-like fashion. At a guess, the tree-like structure of Mathematica expressions means that it is fairly easy for them to avoid cyclic structures. Finally, why not target Java? .NET and Java have extremely similar architectures, and Java operates across all platforms. 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! David Bailey http://www.dbaileyconsultancy.co.uk
- References:
- Mathematica to .NET compiler
- From: Jon Harrop <jon@ffconsultancy.com>
- Mathematica to .NET compiler