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

[Jonathan Shore]

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

> On Mon, Feb 1, 2010 at 11:33 AM, Jonathan Shore <jonathan.sh...@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
_______________________________________________
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list