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

[Diego Frata]

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
diego.frata at gmail.com


On Sat, Jan 30, 2010 at 11:00 PM, Alan McGovern <alan.mcgovern at gmail.com>wrote:

> Hey
>
> On Sat, Jan 30, 2010 at 11:08 PM, James Mansion <
> james at mansionfamily.plus.com> wrote:
>
>> Alan McGovern wrote:
>>
>>> Feel free to contribute the changes required to remove the limitations on
>>> when/where mono performs TCO. That would allow you to contribute F# patches
>>> if you wish.
>>>
>> I'm intrigued - why say that?  I mean - what's the point?  What are you
>> trying to achieve, really?
>>
>
> I say it because he expressed an interest in contributing to mono in the
> email I responded to. He is also, by his own word, quite familiar with VM
> technology in general so he'd be an ideal candidate to contribute a patch if
> he wished to and had the time to do so. He also appears to be quite familiar
> with TCO so he'd know all the cases which would need to be deault with.
> There is no ulterior motive here.
>
> Alan.
>
>
>> If someone has domain knowledge and implementation skills on top of CLR
>> but can show that Mono is defective, its efinitely reasonable to ask them to
>> give 'the mono development community' a test case and bug report.
>>
>> But expecting them to climb the mountain of learning to fiddle with a
>> particular CLR implementation's core is nuts, particularly when they have an
>> alternate that works for them to do their day job. If someone wanted to
>> climb that mountain and make the changes, then presumably they would want to
>> start by reading the copious up to date detailed design documentation and
>> implementation notes on how (and why) it works now,  so that they could size
>> the task.  Oh wait ... :-(
>>
>> Its much, much more efficient for someone who already groks the internals
>> to make fiddly low-level changes, particularly if getting them into the
>> release stream requires a lot of trust relationship with the release
>> masters. I think you do a huge disservice to everyone by trying to get
>> outsiders to work on something like that - or perhaps you just want people
>> with bad news to go away so you can paper over the cracks?
>>
>> Please, ask for test cases and reports.  FWIW I suspect (justa hunch, I'm
>> certainly not an expert) from what's been said that if a calling convention
>> change is needed (and I seem to remember there are some issues that prevent
>> fuller use of LLVM that one might also want to consider if that sort of
>> change is on the cards) then its as much a political and
>> major-version-compatibility issue as it is technical, and once again asking
>> someone to work on patches in such a situation is laughable, given the
>> degree of risk that they might completely waste their time.
>>
>>
>> James
>>
>>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20100201/ef0cb271/attachment-0001.html