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

[Rodrigo Kumpera]

On Sat, Jan 30, 2010 at 12:54 AM, Jon Harrop <jon at ffconsultancy.com> wrote:

> On Saturday 30 January 2010 00:20:11 Jonathan Shore wrote:
> > 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.
>
> There are many different solutions. The simplest would be to use LLVM's
> fast
> calling convention and tail calls as HLVM does.
>

Implementing proper TCO in mono requires 2 things. First is to change the
managed calling convention to
have the caller pop its arguments. Then to lift any other few minor
restrictions. Well probably have similar
restrictions as MS's, such as no TCO on synchronized method.



> > >> 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.
>
> Yes. Technical libraries (e.g. graphing) are far more advanced on .NET. I
> was
> referring only to numerical libraries like BLAS, LAPACK, FFTW and GSL.
>

There is a not very usually explored bit of hidden performance in .NET which
is
runtime code generation. It is trivial to produce code that does runtime
algorithm
specialization. You can even do most of it at high level in C# using
expression trees.



> > Will or does HLVM support the F# dialect of Ocaml as well?
>
> HLVM is designed to be a language agnostic VM so it could support either in
> theory. In practice, I will probably create a new language and any others
> will be ports done by other people. Currently, both OCaml and F# box tuples
> which would be a disaster on HLVM because my GC is not optimized for
> short-lived values. Objectively, F# should not box tuples either. In fact,
> if
> Mono implemented TCO and structs correctly and its own F# then it could
> unbox
> tuples and would see huge performance improvements as a consequence.
>

What's wrong with the way mono implement structs?



By the way, guys, the mono community is very welcoming to both external
contribution
and feedback. So if you guys make a compelling case for TCO, maybe Miguel
can get
someone to have it fixed.

Cheers,
Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20100130/c696cebd/attachment.html