[Mono-list] F# support on mono, performance

Jonathan Shore jonathan.shore at gmail.com
Mon Feb 1 09:17:47 EST 2010


On Feb 1, 2010, at 8:59 AM, Rodrigo Kumpera wrote:

> On Mon, Feb 1, 2010 at 11:33 AM, Jonathan Shore <jonathan.shore at gmail.com> wrote:
> You are entirely right.    I like other quants in finance, use R for a lot of my work, but Java for performance (used to be C++).   My preference is to use a functional language at the level where I use Java.    The only practical choices at this point are Scala (not a big fan) or F#.    There are other implementations for FP such as INRIA's Ocaml, and Jaskell (but much too slow), Clojure (again too slow), etc ...
> 
> I've also been back-reading on the LLVM vs mono code-generation debate.    At this point the main concern stated in not moving over to LLVM completely is the slower JIT'ing in LLVM.    Surely there are different levels of JIT optimisations that can be turned on or off within LLVM?
> 
> LLVM is significantly slower than mono's JIT even if we no optimizations are done and the fast inssel backend is used.

Sorry to hear that.      I wonder whether it is inefficient data-structures and/or are they putting the tree through more phases of analysis before it gets to code generation ...


> 
> 
> At this point LLVM has matured and gained enough momentum that one would suspect that it is more "expensive" for mono development to enhance its own code generation than adopt LLVM.    I raise this issue as there are a number of things that LLVM does quite a bit better.   The effort focused on in-house code generation could be focused on a better more complete LLVM / LLVM-mapping.     Just speaking as a 3rd party looking-in ...
> 
> 
> 
> Today it's not possible to completely switch to LLVM since, for example, it runs on less archs than mono does and a binary with LLVM enabled is 3 times bigger. And I'm not sure if it's even desirable to completely switch, it's something that we'll eventually figure out once our LLVM backend gets more mature.
> 

I recognize that you are targeting mono for embedded devices (i.e. iphone/ipad, etc), so want to control the footprint.    For the niche that represents science, finance, however, we "selfishly" are most interested in performance ;)    So am looking forward to strides in this area with mono.


regards

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20100201/61c706bc/attachment.html 


More information about the Mono-list mailing list