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?

I recognize that the .NET CLR does at up-front JIT compilation, whereas the 
java JVM uses profiling to determine what to JIT and how.    Now that may be 
added complexity, but seems to serve Java well.   The cost of JIT is amortized 
or not done at all for portions of the code.

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 ...


On Feb 1, 2010, at 7:53 AM, Diego Frata wrote:

> Returning to the point of a "compelling case" to implement TCO.
> 
> Lots of EU banks and USA banks are running Linux and are heavy users of C++ 
> for their quant work. They build their models in a variety of languages like 
> Python, Haskell, OCaml, R, etc, then go all the way down to C++/Java for 
> efficiency. I've already seen some interest in F# from the financial 
> industry, but the fact that it's limited to Windows/.NET discourages these 
> people to take a further step.
> 
> From my point of view, these people are tired of Java and C++, they would 
> rather be deploying their models directly to production in a single 
> environment. With a good, fast and stable implementation, I think F# has the 
> strength to bring that.
> 
> Microsoft is not building F# because it's a pretty little thing, they are 
> trying to bring a strong platform for financial and scientific industry.
> 
> Best regards,
> 
> Diego Frata
> [email protected]
> 

_______________________________________________
Mono-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to