[Mono-list] mono performance, 20x differential with Java (what am i doing wrong)

[Jonathan Shore]

On Jan 29, 2010, at 7:19 PM, Jon Harrop wrote:
>> 
>> Jon, I saw your post about that on your blog some time ago.   Someone
>> familiar with Mono claimed otherwise, was therefore uncertain as to whether
>> was addressed or not.
> 
> You should be able to verify my results easily: just run the 8-line example F# 
> program I gave and Mono will stack overflow.
> 
>> I can live some some inefficiency in tail calls provided one does not get
>> stack overflow or some other fatal issue. 
> 
> TCO is broken on Mono, not merely inefficient.
> 

As I have no familiarity with the Mono VM code, no idea what it would take to fix this.   Do any of the mono developers have a view on this?    I suppose we could lift Jon's code and put it into the bug tracking system ...

> 
>> To be honest I 
>> would get more value out of a Ocaml variant wedded to the .NET platform.
> 
> Yes. F# is awesome but only on Windows/.NET and not on Mono.
> 

Hmm, very problematic for me ...


>> There is just so much momentum and available libraries on the two major VMs
>> (CLR and JVM), that would be a huge risk for me at the moment.
> 
> I was actually disappointed with .NET's libraries in the context of technical 
> computing. I felt OCaml had better libraries and it turns out that .NET was 
> about as popular for technical computing as OCaml was when I started. The 
> main exception is WPF but you don't get that with Mono.
> 

I guess it depends where you come from.  First I'll have to be honest and say that I am new to Ocaml.    My FP background is Scheme and some dabbling in Haskell.    I had heard from real-world users of Ocaml (such as the Jane Street capital guys), that the depth of libraries for Ocaml is pretty shallow.    They've invested some years into building that up, but is private work largely.

Now if we are talking about numerical stuff, then yes, there is not much publicly available on either the CLR or JVM.    I was more referring to the tech libraries rather than scientific.    


>> I also 
>> have a significant body of imperative VM-bound code that I need to get
>> access to.    If HLVM could interact with java bytecode or .NET bytecode,
>> would work for me.
> 
> You should be able to compile plain numerical code from JVM/CIL to HLVM easily 
> enough, particularly when HLVM is more complete.
> 

I'll look forward to seeing that.   Are you implying that I would be able to take a bunch of java classes and make them available?    I guess it depends on what you mean by "plain numerical" code.

Will or does HLVM support the F# dialect of Ocaml as well?

>> 
> 
> That doesn't really interest me. F# is so far ahead now that everything else 
> is a toy in comparison from my point of view. HLVM is just a hobby project 
> designed to bring some of the benefits of F# to the open source world for fun 
> but it is a massive undertaking because the open source world doesn't even 
> have any reliable foundations like .NET, let alone decent libraries like WPF 
> built upon them. So I have to build everything from scratch myself. I'm not 
> even sure I will be able to use hardware acceleration due to the poor state 
> of OpenGL drivers on Linux.

Fair enough.   I recognize that you have accomplished quite a bit with the performance of your design.   However, as you allude to, it is quite another thing to enrich it to the point of being a broad-use platform.   For that you need a group of dedicated developers and the momentum to foster that community.  

The MS CLR and Mono may never have the specializations that you have done, for instance, make boxing / unboxing a non-issue (or at least a lot cheaper).    However, they have momentum and breadth.    Getting the best of both would be super, but I understand ... 

> 
> 
> For example, the Haskell implementation of k-nucleotide is only 20% slower 
> than OCaml but the Haskell code is a joke: where the OCaml uses its stdlib's 
> hash table, the Haskell had to do memory allocation manually using "malloc" 
> directly in order to work around serious design flaws in their garbage 
> collector. Not only is this hidden from the casual shootout reader but they 
> even comment their code with total nonsense like "Hash tables are not 
> generally used in functional languages" when what they really mean is "When 
> hash tables are a good solution, Haskell will suck uniquely even among 
> functional languages".

I agree that benchmarks have to be studied carefully to see what is real and what is not.  In the end it is your own application that is the final measure.

>> 
> 
> You cannot work around boxing on the JVM because it lacks value types. Indeed, 
> that is a major advantage of .NET on the JVM that Mono should inherit.
> 

I'm totally with you on .NET over the JVM.    Sun sat on the JVM and Java design for many years.    Catchup now is too late.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20100129/0dcc546c/attachment.html