about OcamIL

about OcamIL

[ben kuin]

hi
I'm waiting for the day that microsoft release f# under a "official"
open source license. It has been promised several times, but its still
only available under the "Microsoft Research Shared Source license
agreement" and
meanwhile I'm not sure if it ever really happens.

So I've stumbled over OcamlL (*) who claims to target the clr vm. The
project seems a littled stalled and the build environment is
configured for cygwin. Besides the website there is very little info
to find on the internet.

Before I waste too much time on this, does somebody has experience
with OcamIL? Is it something that could be refined or are there some
fundamental problems? Do you think it is interesting, or completely
obsolete now with f#?

thanks in advance
ben


* http://www.pps.jussieu.fr/~montela/ocamil

Re: [Caml-list] about OcamIL

[Alain Frisch]

On 05/05/2010 02:06 PM, ben kuin wrote:
> I'm waiting for the day that microsoft release f# under a "official"
> open source license. It has been promised several times, but its still
> only available under the "Microsoft Research Shared Source license
> agreement" and
> meanwhile I'm not sure if it ever really happens.

I cannot answer you question about OCamIL, but if you are interested in 
combining OCaml and .Net programming, you might be interested in our 
CSML tool which allows you to define bindings between the two worlds in 
a high-level way. We use it to develop large OCaml applications with a 
Winforms GUI and other .Net components.

http://www.lexifi.com/csml/


Regards,

Alain

Re: [Caml-list] about OcamIL

[ben kuin]

> 1. [...] it would still require some time to rewrite a few parts.

Release early, release often. Maybe you put it under your name on
sourceforge, if you are afraid to put potentially non-buildable code
under the flags of lexifi.

> 2. Similarly, we rely on our "extended standard library" (a collection of
> general purpose modules).

That sounds interesting!

> Again, it would take some time to extract the few
> needed function to make a standalone distribution.

Release early, release o...

> 3. [...] At some point, we planned to sell a version of CSML as
> an extra module to this platform

If this is about biz vs. oss, then it could be a solution to go the
path of PyQT:
- offer of a GPL version
- sell a version that can be used commercially




On Thu, May 6, 2010 at 4:40 AM, Alain Frisch <alain.frisch@lexifi.com> wrote:
> On 05/05/2010 11:46 PM, ben kuin wrote:
>>
>> thats interesting indeed, is there a particular reason you wont
>> release the csml compiler sources and provide only the binaries?
>
> Yes, there are several reasons:
>
> 1. The code uses some local extensions to the OCaml compiler that are not
> available in the INRIA version; this is less true today because some of our
> extensions have been integrated upstream, but it would still require some
> time to rewrite a few parts.
>
> 2. Similarly, we rely on our "extended standard library" (a collection of
> general purpose modules). Again, it would take some time to extract the few
> needed function to make a standalone distribution.
>
> 3. We sell a development platform for financial applications, which includes
> our modified version of OCaml and advanced libraries for the manipulation of
> financial concepts. At some point, we planned to sell a version of CSML as
> an extra module to this platform (the public version of CSML does not
> support some extra features). It hasn't been formally decided yet, but we
> might change our plans regarding this issue.
>
>
> We did not get any feedback from the community regarding this tool, so we
> haven't felt any motivation to address point 1 and 2 above, or to reconsider
> our position in point 3.  If you plan to use CSML, let us know about your
> projects, and we might find some arrangement (either a custom license with
> source code at no charge for you, or a real open-source license).
>
> Regards,
>
> Alain Frisch
>
>
>

Re: [Caml-list] about OcamIL

[Eray Ozkural]

Or use the real ocaml on a real OS (^_^)

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara

Re: [Caml-list] about OcamIL

[Ed Keith]

--- On Wed, 5/5/10, Eray Ozkural <examachine@gmail.com> wrote:

> Or use the real ocaml on a real OS
> (^_^)
> 

I do not understand UNIX bigotry. 

Yes, Unix is technically superior to Windows. But Plan 9 is technically superior to Unix. But I doubt Eray is running Plan 9.

More computers run Windows than all other OS's combined. If you want a large user base you need to support Windows. If you do not care about the size of your user base, write for Plan 9. 

Personalty I try to support as many systems as practical.

It bothers me that the Ocaml community seems to consider Windows developers as second class citizens. Until this changes Ocaml will never be a main stream language. F# may eat it's lunch. But F# is tied to Windows, Ocaml has the potential to be multi-platform. I just wish it would live up to this potential.

   -EdK

Ed Keith
e_d_k@yahoo.com

Blog: edkeith.blogspot.com




      

Re: [Caml-list] about OcamIL

[Eray Ozkural]

http://caml.inria.fr/download.en.html

Well, it is actually available on Windows. And mind you, there is some
popular windows software written in ocaml. We were taking a look at
haxe the other day. The F# makes use of the (pretty good designed)
.net CLR. Which isn't a bad thing at all, but it's not my cup of tea.
:) On the other hand, starting an ocaml interpreter on windows makes
me feel a bit like a caveman touching a spaceship's gleaming surface.

Cheers and take it easy,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara

Re: [Caml-list] about OcamIL

[Vincent Aravantinos]

Le 5 mai 10 à 21:16, Ed Keith a écrit :

> --- On Wed, 5/5/10, Eray Ozkural <examachine@gmail.com> wrote:
>
>> Or use the real ocaml on a real OS
>> (^_^)
>>
>
> I do not understand UNIX bigotry.
>
> Yes, Unix is technically superior to Windows. But Plan 9 is  
> technically superior to Unix. But I doubt Eray is running Plan 9.
>
> More computers run Windows than all other OS's combined. If you want  
> a large user base you need to support Windows. If you do not care  
> about the size of your user base, write for Plan 9.
>
> Personalty I try to support as many systems as practical.
>
> It bothers me that the Ocaml community seems to consider Windows  
> developers as second class citizens. Until this changes Ocaml will  
> never be a main stream language. F# may eat it's lunch. But F# is  
> tied to Windows, Ocaml has the potential to be multi-platform. I  
> just wish it would live up to this potential.

I guess you shouldn't take some stup** trollism as representing the  
whole community thinking though.
I am not a Windows user but this kind of "Windows sucks" remark pisses  
me off.

Still, it's a fact that it's hard to use ocaml on Windows but there  
are frequently some posts on this list showing that many ocamlers do  
care about Windows.
The Ocaml Team explicitly requests some help of windows users to test  
the releases because they know it's a downside of ocaml.
I think this shows that they really seem to care about it and try to  
improve.

V.

Re: [Caml-list] about OcamIL

[ben kuin]

I think the main problem is the lack of cross platform gui that looks
good on windows.

LablTk: ok only for simple gui
LablGtk:    fragile on linux, bad on windows
qt:      I once tried to create bindings for a newer qt release ( >
4.2), I didn't finished it, but I think it would be doable. The big
problem though is the huge qt dependency with this blackboxy C++/moc
thing .


On Wed, May 5, 2010 at 6:13 PM, Vincent Aravantinos
<vincent.aravantinos@gmail.com> wrote:
>
> Le 5 mai 10 à 21:16, Ed Keith a écrit :
>
>> --- On Wed, 5/5/10, Eray Ozkural <examachine@gmail.com> wrote:
>>
>>> Or use the real ocaml on a real OS
>>> (^_^)
>>>
>>
>> I do not understand UNIX bigotry.
>>
>> Yes, Unix is technically superior to Windows. But Plan 9 is technically
>> superior to Unix. But I doubt Eray is running Plan 9.
>>
>> More computers run Windows than all other OS's combined. If you want a
>> large user base you need to support Windows. If you do not care about the
>> size of your user base, write for Plan 9.
>>
>> Personalty I try to support as many systems as practical.
>>
>> It bothers me that the Ocaml community seems to consider Windows
>> developers as second class citizens. Until this changes Ocaml will never be
>> a main stream language. F# may eat it's lunch. But F# is tied to Windows,
>> Ocaml has the potential to be multi-platform. I just wish it would live up
>> to this potential.
>
> I guess you shouldn't take some stup** trollism as representing the whole
> community thinking though.
> I am not a Windows user but this kind of "Windows sucks" remark pisses me
> off.
>
> Still, it's a fact that it's hard to use ocaml on Windows but there are
> frequently some posts on this list showing that many ocamlers do care about
> Windows.
> The Ocaml Team explicitly requests some help of windows users to test the
> releases because they know it's a downside of ocaml.
> I think this shows that they really seem to care about it and try to
> improve.
>
> V.
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] about OcamIL

[Eray Ozkural]

On Thu, May 6, 2010 at 1:36 AM, ben kuin <benkuin@gmail.com> wrote:
> I think the main problem is the lack of cross platform gui that looks
> good on windows.
>
> LablTk: ok only for simple gui
> LablGtk:    fragile on linux, bad on windows
> qt:      I once tried to create bindings for a newer qt release ( >
> 4.2), I didn't finished it, but I think it would be doable. The big
> problem though is the huge qt dependency with this blackboxy C++/moc
> thing .

yeah i tried my hand once too :/ i've been thinking about this.
perhaps the best bet is to write a proper gui toolkit in ocaml. after
all this is the most productive programming language, right? :D i
remember a lot of interesting gui frameworks and approaches for
functional languages. i bet we could create a much better api than any
of those once we get rid of the low-level low-tech approach to gui
programming. why don't we write a google summer of code proposal for
that? perhaps some enthusiastic students would take up the challenge.
it could be divided into some stages, for instance abstracting over
x11/win32(horrors!) windowing systems first....

cheers,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

Re: [Caml-list] about OcamIL

[ben kuin]

> for instance abstracting over
> x11/win32(horrors!) windowing systems first....

you're an optimist :-)

On Wed, May 5, 2010 at 7:13 PM, Eray Ozkural <examachine@gmail.com> wrote:
> On Thu, May 6, 2010 at 1:36 AM, ben kuin <benkuin@gmail.com> wrote:
>> I think the main problem is the lack of cross platform gui that looks
>> good on windows.
>>
>> LablTk: ok only for simple gui
>> LablGtk:    fragile on linux, bad on windows
>> qt:      I once tried to create bindings for a newer qt release ( >
>> 4.2), I didn't finished it, but I think it would be doable. The big
>> problem though is the huge qt dependency with this blackboxy C++/moc
>> thing .
>
> yeah i tried my hand once too :/ i've been thinking about this.
> perhaps the best bet is to write a proper gui toolkit in ocaml. after
> all this is the most productive programming language, right? :D i
> remember a lot of interesting gui frameworks and approaches for
> functional languages. i bet we could create a much better api than any
> of those once we get rid of the low-level low-tech approach to gui
> programming. why don't we write a google summer of code proposal for
> that? perhaps some enthusiastic students would take up the challenge.
> it could be divided into some stages, for instance abstracting over
> x11/win32(horrors!) windowing systems first....
>
> cheers,
>
> --
> Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
> http://groups.yahoo.com/group/ai-philosophy
> http://myspace.com/arizanesil http://myspace.com/malfunct
>

Re: [Caml-list] about OcamIL

[Tim Hanson]

lablGTK2 on linux is not fragile!  Its robust, well designed, and
produces nice guis!
(at least on debian.  props to the packagers and developers, if you're
listening)

On Wed, May 5, 2010 at 6:36 PM, ben kuin <benkuin@gmail.com> wrote:
> I think the main problem is the lack of cross platform gui that looks
> good on windows.
>
> LablTk: ok only for simple gui
> LablGtk:    fragile on linux, bad on windows
> qt:      I once tried to create bindings for a newer qt release ( >
> 4.2), I didn't finished it, but I think it would be doable. The big
> problem though is the huge qt dependency with this blackboxy C++/moc
> thing .

Re: [Caml-list] about OcamIL

[ben kuin]

keith, a few thoughts, ... before I've worked with linux I was a
windows guy. I remember the day (forgot the context though) when I
installed the ocaml package on my dell/windows-xp/laptop (yuk) . Since
the workflow on windows is very gui centric, you can't help to get
very sensible how a particular app looks and feels. I can tell you
those "weird" guis (tcl/tk?) scared the hell out of me and I hoped I
could get rid of the stuff without breaking the registry :-).

Anyway, I think in order to provide something that the next windows
user would like to work with, all the ocaml gui apps should be feel
very much more native.

Maybe the time would be better invested by an effort to port
Ocaml-Batteries to F#. I mean why not?


On Wed, May 5, 2010 at 3:16 PM, Ed Keith <e_d_k@yahoo.com> wrote:
> --- On Wed, 5/5/10, Eray Ozkural <examachine@gmail.com> wrote:
>
>> Or use the real ocaml on a real OS
>> (^_^)
>>
>
> I do not understand UNIX bigotry.
>
> Yes, Unix is technically superior to Windows. But Plan 9 is technically superior to Unix. But I doubt Eray is running Plan 9.
>
> More computers run Windows than all other OS's combined. If you want a large user base you need to support Windows. If you do not care about the size of your user base, write for Plan 9.
>
> Personalty I try to support as many systems as practical.
>
> It bothers me that the Ocaml community seems to consider Windows developers as second class citizens. Until this changes Ocaml will never be a main stream language. F# may eat it's lunch. But F# is tied to Windows, Ocaml has the potential to be multi-platform. I just wish it would live up to this potential.
>
>   -EdK
>
> Ed Keith
> e_d_k@yahoo.com
>
> Blog: edkeith.blogspot.com
>
>
>
>
>
>

Re: [Caml-list] about OcamIL

[Ed Keith]

--- On Wed, 5/5/10, ben kuin <benkuin@gmail.com> wrote:

> From: ben kuin <benkuin@gmail.com>
> Subject: Re: [Caml-list] about OcamIL
> To: "Ed Keith" <e_d_k@yahoo.com>, caml-list@yquem.inria.fr
> Date: Wednesday, May 5, 2010, 6:18 PM
> keith, a few thoughts, ... before
> I've worked with linux I was a
> windows guy. I remember the day (forgot the context though)
> when I
> installed the ocaml package on my dell/windows-xp/laptop
> (yuk) . Since
> the workflow on windows is very gui centric, you can't help
> to get
> very sensible how a particular app looks and feels. I can
> tell you
> those "weird" guis (tcl/tk?) scared the hell out of me and
> I hoped I
> could get rid of the stuff without breaking the registry
> :-).
> 
> Anyway, I think in order to provide something that the next
> windows
> user would like to work with, all the ocaml gui apps should
> be feel
> very much more native.
> 
> Maybe the time would be better invested by an effort to
> port
> Ocaml-Batteries to F#. I mean why not?
> 
> 
> On Wed, May 5, 2010 at 3:16 PM, Ed Keith <e_d_k@yahoo.com>
> wrote:

Actually I always have one or more command prompts open on my Windows box. A command line is so much more efficient than a GUI for many tasks.

    -EdK

Ed Keith
e_d_k@yahoo.com

Blog: edkeith.blogspot.com



      

Re: [Caml-list] about OcamIL

[Dmitry Bely]

On Wed, May 5, 2010 at 11:16 PM, Ed Keith <e_d_k@yahoo.com> wrote:

> It bothers me that the Ocaml community seems to consider Windows developers as second class citizens. Until this changes
> Ocaml will never be a main stream language.

I think it's not really that bad. Ocaml developers support Windows as
a first class platform. Many Ocaml libraries can be build under
Windows without a problem. And now GODI supports Windows too.

> F# may eat it's lunch. But F# is tied to Windows,

Ironically it's also not entirely true. F# works well under Mono/Unix.
Maybe it will even be faster than Ocaml for some applications due to
threads running in parallel on multiple cores. But F# is very
different from Ocaml.

- Dmitry Bely

Re: [Caml-list] about OcamIL

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote:
> Ironically it's also not entirely true. F# works well under Mono/Unix.
> 
> - Dmitry Bely
>

A little off topic, but how is Mono/Unix these days?  Last I checked (>2 years 
ago) it implemented the basic libraries and runtimes but had terrible 
performance.  Is it now on par with Windows?

Thanks,

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFL4u9DfIRcEFL/JewRAlvRAJ4t7waiAbNJL7zyo/baAOzZxjiM/QCfZkST
dakL+vN3hqa/Tff2F+Qe20A=
=pURF
-----END PGP SIGNATURE-----

Re: [Caml-list] about OcamIL

[Dmitry Bely]

> On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote:
>> Ironically it's also not entirely true. F# works well under Mono/Unix.
>>
> A little off topic, but how is Mono/Unix these days?  Last I checked (>2 years
> ago) it implemented the basic libraries and runtimes but had terrible
> performance.  Is it now on par with Windows?

It's hard to say: personally I don't use Mono (neither Windows nor
Linux) yet. But indeed I was overoptimistic. Mono still uses Boehm GC
so it should be slow enough. Nevertheless things are changing:

http://www.mono-project.com/Compacting_GC
http://lists.ximian.com/pipermail/mono-devel-list/2009-November/033421.html

Let's wait for mono 2.8 and see how the new generational GC works.

- Dmitry Bely

Re: about OcamIL

[Sylvain Le Gall]

On 07-05-2010, Dmitry Bely <dmitry.bely@gmail.com> wrote:
>> On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote:
>>> Ironically it's also not entirely true. F# works well under Mono/Unix.
>>>
>> A little off topic, but how is Mono/Unix these days?  Last I checked (>2 years
>> ago) it implemented the basic libraries and runtimes but had terrible
>> performance.  Is it now on par with Windows?
>
> It's hard to say: personally I don't use Mono (neither Windows nor
> Linux) yet. But indeed I was overoptimistic. Mono still uses Boehm GC
> so it should be slow enough. Nevertheless things are changing:
>
> http://www.mono-project.com/Compacting_GC
> http://lists.ximian.com/pipermail/mono-devel-list/2009-November/033421.html
>
> Let's wait for mono 2.8 and see how the new generational GC works.
>

I can give you a very personnal POV, I don't really use Mono but I
attended various demonstration of it, by Miguel de Icaza, some people
from Second Life and some people from the me Moonlight project, back in
February at FOSDEM 2010. Don't take my opinion for sure.

Overall the effort about Mono is impressive but it doesn't yet match
C#/.NET in term of performance and stability. During the demonstration a
lot of things didn't work (video in Silverlight, compilation of various
compilation unit). 

I was not very impressed by the whole Mono, I acknowledge the effort
toward a compatibility with .NET. But since the other end doesn't seem
cooperative, they will have a lot of work ahead.

Concerning F#/Mono, I am not sure that the Mono version will be
supported in the future. Now F# is a first class language in Visual
Studio, so I suppose they will put a bigger effort to integrate F# with
Visual Studio (e.g. to be able to build GUI application using a GUI
builder...) This integration will probably be a higher priority than the
Mono compatibility and probably will reduce it. 

My 2 cents,
Sylvain Le Gall

ps: this is really a personnal POV and guess, I am not a .NET/Mono
expert, only someone who have some interests in it.

RE: [Caml-list] about OcamIL

[Jon Harrop]

> A little off topic, but how is Mono/Unix these days?  Last I checked
> (>2 years ago) it implemented the basic libraries and runtimes but had
terrible
> performance.  Is it now on par with Windows?

Still leaks memory, has broken TCO and runs like a dog. Mono has also fallen
even farther behind now that .NET 4 is out. However, they have at least
stated that they intend to start trying to support F# on Mono. Then again,
they stated about 6 years ago they were going to replace their crappy
conservative GC with one that might actually work but they never managed to
do that either...

Cheers,
Jon.

Re: [Caml-list] about OcamIL

[ben kuin]

> A little off topic, but how is Mono/Unix these days?
>> Still leaks memory,
you refer to your examinations?
(http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-memory.html?showComment=1233522107493#c7872630239059031867)
where you say yes and the mono devs are say no to memory leaking?

>> has broken TCO
Again, I think other people do not have the same opion on this (
http://flyingfrogblog.blogspot.com/2009/01/mono-does-not-support-tail-calls.html)

>> and runs like a dog
I think this on the other hand is indeed a problem and has been
documented seriously (also by you:
http://flyingfrogblog.blogspot.com/2009/01/mono-22.html)

I've introduced the post with some license related concerns, maybe I
should take a step back and think about what I want:

1. - programming in a ML like language ( especially the caml family
since I really like those lightweigt type definitions and the pattern
matching that can be applied on those)

2. - high performance runtime, preferably a jit based vm, no problems with TCO

3. - a true open source license (approved by Open Source Initiative or
by Free Software Foundation)

I think this 3 point are REASONABLE but the combination of those 3
items is INEXISTENT.

Ocaml: the vm is not very fast (no jit AFAIK)

F#: No open source license so far. Bad runtime performance on mono.

Ocaml on HLVM: I would appreciate if Jon could make a clear statement
if this is something serious or just a little toy.

Scala: Not really a ML language: I think it's kind of fun to try to
emulate ocaml features or try to port ocaml apps to scala. The problem
is the actual work is never going to be finished. I have some concerns
the the runtime performance is unpredictable (no TCO, a lot of hacks
into the JVM)

Yeti: I like the language, but it is in a experimental stage

Nekoml: Supercool project, but the vm is not the fastest and jit runs
only on x86 platforms


So I guess the best thing would be to use good ol Ocaml in native mode...?

A last idea: What do you think about libjit? They claim that a jvm/clr
like runtime could be built in weeks. Wouldn't it be nice to have a
fast vm for Ocaml (ocamljit) ? Does someone has experience with this,
I think writing a fast vm is hard, but a fast vm for a functional
language is nearly impossible? Maybe OcamIL could then be used as a
model for a jit backend, since its MSIL output already runs on libjit
(DotGnu, alias pnet)




On Mon, May 10, 2010 at 11:53 PM, Jon Harrop
<jonathandeanharrop@googlemail.com> wrote:
>> A little off topic, but how is Mono/Unix these days?  Last I checked
>> (>2 years ago) it implemented the basic libraries and runtimes but had
> terrible
>> performance.  Is it now on par with Windows?
>
> Still leaks memory, has broken TCO and runs like a dog. Mono has also fallen
> even farther behind now that .NET 4 is out. However, they have at least
> stated that they intend to start trying to support F# on Mono. Then again,
> they stated about 6 years ago they were going to replace their crappy
> conservative GC with one that might actually work but they never managed to
> do that either...
>
> Cheers,
> Jon.
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] about OcamIL

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Tuesday 11 May 2010 07:22:56 am ben kuin wrote:
> I think this 3 point are REASONABLE but the combination of those 3
> items is INEXISTENT.
>
> Ocaml: the vm is not very fast (no jit AFAIK)
>
>
> So I guess the best thing would be to use good ol Ocaml in native mode...?
>

What do you mean by vm?  OCaml doesn't have a vm like the jvm.  Although 
there's been some great work on compiling OCaml for the jvm.  OCaml does have 
a toplevel interpreter.  It even has a native mode toplevel now that's 
suppose to be fast (anyone have any experience with this?).  So that's good.  
And of course as you pointed out you can always compile OCaml code to native 
machine code which has always had good performance.

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD4DBQFL6YhCfIRcEFL/JewRAuB7AJ9tDRHgDJGt3+VqmX4u/IxU+vRXyQCWL3NX
SkKhph4GC7xGA85ilSspTw==
=IxIG
-----END PGP SIGNATURE-----

Re: [Caml-list] about OcamIL

[Raoul Duke]

On Tue, May 11, 2010 at 9:39 AM, Peng Zang <peng.zang@gmail.com> wrote:
> And of course as you pointed out you can always compile OCaml code to native
> machine code which has always had good performance.

i was under the impression the main complaint is lack of top-notch
support for concurrency?

Re: [Caml-list] about OcamIL

[ben kuin]

> OCaml doesn't have a vm like the jvm.
ocamlc compiles to bytecode
ocamlrun interprets the bytecode
bytecode interpreter == vm
hence ocaml has a vm

On Tue, May 11, 2010 at 6:39 PM, Peng Zang <peng.zang@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Tuesday 11 May 2010 07:22:56 am ben kuin wrote:
>> I think this 3 point are REASONABLE but the combination of those 3
>> items is INEXISTENT.
>>
>> Ocaml: the vm is not very fast (no jit AFAIK)
>>
>>
>> So I guess the best thing would be to use good ol Ocaml in native mode...?
>>
>
> What do you mean by vm?  OCaml doesn't have a vm like the jvm.  Although
> there's been some great work on compiling OCaml for the jvm.  OCaml does have
> a toplevel interpreter.  It even has a native mode toplevel now that's
> suppose to be fast (anyone have any experience with this?).  So that's good.
> And of course as you pointed out you can always compile OCaml code to native
> machine code which has always had good performance.
>
> Peng
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
>
> iD4DBQFL6YhCfIRcEFL/JewRAuB7AJ9tDRHgDJGt3+VqmX4u/IxU+vRXyQCWL3NX
> SkKhph4GC7xGA85ilSspTw==
> =IxIG
> -----END PGP SIGNATURE-----
>

Re: [Caml-list] about OcamIL

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah, I guess I think of ocamlrun as just an interpreter.  But you're right, 
that's also a vm.

Peng

On Tuesday 11 May 2010 07:47:25 pm ben kuin wrote:
> > OCaml doesn't have a vm like the jvm.
>
> ocamlc compiles to bytecode
> ocamlrun interprets the bytecode
> bytecode interpreter == vm
> hence ocaml has a vm
>
> On Tue, May 11, 2010 at 6:39 PM, Peng Zang <peng.zang@gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Tuesday 11 May 2010 07:22:56 am ben kuin wrote:
> >> I think this 3 point are REASONABLE but the combination of those 3
> >> items is INEXISTENT.
> >>
> >> Ocaml: the vm is not very fast (no jit AFAIK)
> >>
> >>
> >> So I guess the best thing would be to use good ol Ocaml in native
> >> mode...?
> >
> > What do you mean by vm?  OCaml doesn't have a vm like the jvm.  Although
> > there's been some great work on compiling OCaml for the jvm.  OCaml does
> > have a toplevel interpreter.  It even has a native mode toplevel now
> > that's suppose to be fast (anyone have any experience with this?).  So
> > that's good. And of course as you pointed out you can always compile
> > OCaml code to native machine code which has always had good performance.
> >
> > Peng
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.7 (GNU/Linux)
> >
> > iD4DBQFL6YhCfIRcEFL/JewRAuB7AJ9tDRHgDJGt3+VqmX4u/IxU+vRXyQCWL3NX
> > SkKhph4GC7xGA85ilSspTw==
> > =IxIG
> > -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFL6gscfIRcEFL/JewRAgWBAJ93Hee3UhXDbLdX+bCuQs3Vwx72mQCaA/e4
G5U5E2pOf5NY3QvcciaenuU=
=W6jj
-----END PGP SIGNATURE-----

RE: [Caml-list] about OcamIL

[Jon Harrop]

Peng Zang wrote:
> It even has a native mode toplevel now that's
> suppose to be fast (anyone have any experience with this?).

You mean "ocamlnat"? The performance was great but it was buggy and I think
it never made it into mainline OCaml.

Cheers,
Jon.

Re: [Caml-list] about OcamIL

[Raoul Duke]

> 1. - programming in a ML like language ( especially the caml family
> since I really like those lightweigt type definitions and the pattern
> matching that can be applied on those)
>
> 2. - high performance runtime, preferably a jit based vm, no problems with TCO
>
> 3. - a true open source license (approved by Open Source Initiative or
> by Free Software Foundation)
>
> I think this 3 point are REASONABLE but the combination of those 3
> items is INEXISTENT.

i, for one, am hoping Shen comes through for us.

http://groups.google.com/group/qilang

RE: [Caml-list] about OcamIL

[Jon Harrop]

Ben Kuin wrote:
> > A little off topic, but how is Mono/Unix these days?
> >> Still leaks memory,
> you refer to your examinations?
> (http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-
> memory.html?showComment=1233522107493#c7872630239059031867)
> where you say yes and the mono devs are say no to memory leaking?

Yes.

> >> has broken TCO
> Again, I think other people do not have the same opion on this (
> http://flyingfrogblog.blogspot.com/2009/01/mono-does-not-support-tail-
> calls.html)

Yes. They are wrong.

> I've introduced the post with some license related concerns, maybe I
> should take a step back and think about what I want:
> 
> 1. - programming in a ML like language ( especially the caml family
> since I really like those lightweigt type definitions and the pattern
> matching that can be applied on those)
> 
> 2. - high performance runtime, preferably a jit based vm, no problems
> with TCO
> 
> 3. - a true open source license (approved by Open Source Initiative or
> by Free Software Foundation)
> 
> I think this 3 point are REASONABLE but the combination of those 3
> items is INEXISTENT.

I'm afraid the situation is far worse. Even if you relax your conditions
from "ML-like" to any functional language and even allow broken TCO, there
are not only no language implementations satisfying those weaker conditions
but nobody is even trying to create such a language implementation.

> Ocaml on HLVM: I would appreciate if Jon could make a clear statement
> if this is something serious or just a little toy.

HLVM is not yet ready for serious use and it may well never compile OCaml
but at least it is now compiling code like this:

http://flyingfrogblog.blogspot.com/2010/04/variant-types-and-pattern-matchin
g-in.html

> A last idea: What do you think about libjit? They claim that a jvm/clr
> like runtime could be built in weeks. Wouldn't it be nice to have a
> fast vm for Ocaml (ocamljit) ? Does someone has experience with this,
> I think writing a fast vm is hard, but a fast vm for a functional
> language is nearly impossible? Maybe OcamIL could then be used as a
> model for a jit backend, since its MSIL output already runs on libjit
> (DotGnu, alias pnet)

I think LLVM is a much better choice than libjit. Once you've got that kind
of solid foundation to build upon and a decent language like OCaml to write
in, you can write a decent FPL implementation in a few man-months. The
problem is finding the time...

Cheers,
Jon.

RE: [Caml-list] about OcamIL

[forum]

Jon Harrop <jonathandeanharrop@googlemail.com> a écrit :

> Ben Kuin wrote:

>> I've introduced the post with some license related concerns, maybe I
>> should take a step back and think about what I want:
>>
>> 1. - programming in a ML like language ( especially the caml family
>> since I really like those lightweigt type definitions and the pattern
>> matching that can be applied on those)
>>
>> 2. - high performance runtime, preferably a jit based vm, no problems
>> with TCO
>>
>> 3. - a true open source license (approved by Open Source Initiative or
>> by Free Software Foundation)
>>
>> I think this 3 point are REASONABLE but the combination of those 3
>> items is INEXISTENT.
>
> I'm afraid the situation is far worse. Even if you relax your conditions
> from "ML-like" to any functional language and even allow broken TCO, there
> are not only no language implementations satisfying those weaker conditions
> but nobody is even trying to create such a language implementation.

Putting aside an answer I posted this morning on a parallel thread,
I will just present some counter examples to this claim.

Limiting myself to the JVM, and not even trying to be exhaustive, I  
can find...

... in the LISP family :
   - Clojure - http://clojure.org/ - Eclipse Public License

... in the Scheme family :
   - Bigloo - http://www-sop.inria.fr/indes/fp/Bigloo/ - GPL / LGPL
   - Kawa - http://www.gnu.org/software/kawa/ - X11 / MIT license
   - SISC - http://sisc-scheme.org/ - GPL

... in the ML family:
   - Yeti - http://mth.github.com/yeti/

... in the Haskell family:
   - CAL - http://openquark.org/Open_Quark/Welcome.html - BSD-like license

... in its own family:
   - Scala - http://www.scala-lang.org


Moreover, at least Scala and Bigloo deliver excellent performances.


Regards,

Xavier Clerc

RE: [Caml-list] about OcamIL

[Jon Harrop]

Xavier Clerc wrote:
> Limiting myself to the JVM...
> Moreover, at least Scala and Bigloo deliver excellent performances.

I have benchmarks where the JVM is well over 10x slower than .NET. So I do
not regard any JVM-based language as "high performance".

Cheers,
Jon.

Re: [Caml-list] about OcamIL

[Eray Ozkural]

On Fri, May 14, 2010 at 1:40 PM, Jon Harrop
<jonathandeanharrop@googlemail.com> wrote:
> Xavier Clerc wrote:
>> Limiting myself to the JVM...
>> Moreover, at least Scala and Bigloo deliver excellent performances.
>
> I have benchmarks where the JVM is well over 10x slower than .NET. So I do
> not regard any JVM-based language as "high performance".

You got a point there.

JVM has a ridiculous performance, not fitting for any computationally expensive
operation. At best it's some kind of mudware for data plumbing and
simple network
applications. The memory system, whatever it is doing, is absolutely
terrible. I've
implemented some semi-sophisticated information retrieval code on it
(related to a
search engine) and I've seen that it's not only much slower but
horribly bloated
memory-wise as well. You can only use it for toy problems.

And there are even papers using Java/MPI for high performance computing!
Using Java still turns any computer to a Commodore 64, so why are
people using it?

Cheers,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

Re: [Caml-list] about OcamIL

[forum]

Le 14 mai 2010 à 12:58, Eray Ozkural a écrit :

> On Fri, May 14, 2010 at 1:40 PM, Jon Harrop
> <jonathandeanharrop@googlemail.com> wrote:
>> Xavier Clerc wrote:
>>> Limiting myself to the JVM...
>>> Moreover, at least Scala and Bigloo deliver excellent performances.
>> 
>> I have benchmarks where the JVM is well over 10x slower than .NET. So I do
>> not regard any JVM-based language as "high performance".
> 
> You got a point there.
> 
> JVM has a ridiculous performance, not fitting for any computationally expensive
> operation. At best it's some kind of mudware for data plumbing and
> simple network
> applications. The memory system, whatever it is doing, is absolutely
> terrible. I've
> implemented some semi-sophisticated information retrieval code on it
> (related to a
> search engine) and I've seen that it's not only much slower but
> horribly bloated
> memory-wise as well. You can only use it for toy problems.
> 
> And there are even papers using Java/MPI for high performance computing!
> Using Java still turns any computer to a Commodore 64, so why are
> people using it?

If it is not considered as too much off-topic for this mailing list,
could one of you provide references to such benchmarks rather
than just state that they exist.


Regards,

Xavier Clerc

Re: [Caml-list] about OcamIL

[forum]

Le 14 mai 2010 à 12:40, Jon Harrop a écrit :

> Xavier Clerc wrote:
>> Limiting myself to the JVM...
>> Moreover, at least Scala and Bigloo deliver excellent performances.
> 
> I have benchmarks where the JVM is well over 10x slower than .NET. So I do
> not regard any JVM-based language as "high performance".

Quite ironically, by scratching the surface, one would discover that both quoted
projects can also target .NET (not tested that though).


Regards,

Xavier Clerc

RE: [Caml-list] about OcamIL

[Jon Harrop]

Xavier Clerc:
> Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
> > Xavier Clerc wrote:
> >> Limiting myself to the JVM...
> >> Moreover, at least Scala and Bigloo deliver excellent performances.
> >
> > I have benchmarks where the JVM is well over 10x slower than .NET. So
> > I do not regard any JVM-based language as "high performance".
> 
> Quite ironically, by scratching the surface, one would discover that
> both quoted projects can also target .NET (not tested that though).

Does Bigloo.NET support value types? Does Scala.NET use .NET (2.0) generics?
Not AFAICT. Name dropping them in the context of "high performance" language
implementations is more than a little bit silly...

Cheers,
Jon.

RE: [Caml-list] about OcamIL

[forum]

Jon Harrop <jonathandeanharrop@googlemail.com> a écrit :

> Xavier Clerc:
>> Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
>> > Xavier Clerc wrote:
>> >> Limiting myself to the JVM...
>> >> Moreover, at least Scala and Bigloo deliver excellent performances.
>> >
>> > I have benchmarks where the JVM is well over 10x slower than .NET. So
>> > I do not regard any JVM-based language as "high performance".
>>
>> Quite ironically, by scratching the surface, one would discover that
>> both quoted projects can also target .NET (not tested that though).
>
> Does Bigloo.NET support value types? Does Scala.NET use .NET (2.0) generics?
> Not AFAICT. Name dropping them in the context of "high performance" language
> implementations is more than a little bit silly...

First off, public insult seems quite superfluous.
We should be able to handle a heated debate without resorting to that.

And I still wait for a clear statement of your level for "high performance",
and references to benchmarks that back up your claims in this thread.
As you seem to come from an academic background, I expect facts
and references, and not ad hominem attacks and fuzzy unbacked claims.
Unless you show that neither Bigloo nor Scala meet your (to be defined)
criteria for "high performance", my counterexamples still stand.

It may just end up that we have different perceptions of "high performance",
and of the trade-offs we are going to make in our language / platform choices.


Regards,

Xavier Clerc

RE: [Caml-list] about OcamIL

[Jon Harrop]

Xavier Clerc wrote:
> Jon Harrop <jonathandeanharrop@googlemail.com> a écrit :
> > Xavier Clerc:
> >> Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
> >> > Xavier Clerc wrote:
> >> >> Limiting myself to the JVM...
> >> >> Moreover, at least Scala and Bigloo deliver excellent
> performances.
> >> >
> >> > I have benchmarks where the JVM is well over 10x slower than .NET.
> So
> >> > I do not regard any JVM-based language as "high performance".
> >>
> >> Quite ironically, by scratching the surface, one would discover that
> >> both quoted projects can also target .NET (not tested that though).
> >
> > Does Bigloo.NET support value types? Does Scala.NET use .NET (2.0)
> > generics?
> > Not AFAICT. Name dropping them in the context of "high performance"
> > language
> > implementations is more than a little bit silly...
> 
> First off, public insult seems quite superfluous.

I was not trying to insult you. Your examples are silly because they are
incomplete and untested. Do you even have either of them working right now?
AFAICT, Scala.NET is known not to work and Bigloo.NET is still have dozens
of core bugs fixed.

> We should be able to handle a heated debate without resorting to that.

I don't think this is heated at all. We were talking about "high
performance" languages and you cited a bunch of languages that get whipped
by Python on this benchmark:

 
http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.
html

> And I still wait for a clear statement of your level for "high
> performance",

Within 2x of ANSI C compiled with gcc on all practically-relevant benchmarks
without dropping to low-level code, e.g. GHC's FFI in Haskell.

> and references to benchmarks that back up your claims in this thread.

  http://fsharpnews.blogspot.com/2010/05/java-vs-f.html

> As you seem to come from an academic background, I expect facts
> and references, and not ad hominem attacks and fuzzy unbacked claims.

An ad-hominem attack is an attack against a person. I attacked your
examples, not you.

> Unless you show that neither Bigloo nor Scala meet your (to be defined)
> criteria for "high performance", my counterexamples still stand.

Are you talking about Bigloo.NET and Scala.NET or have you gone back to the
original discussion about JVM-based languages?

Scala on the JVM is 7x slower than C++ on this benchmark:

 
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scala&lan
g2=gpp

The JVM's hash table is 17x slower than .NET's on this benchmark:

  http://fsharpnews.blogspot.com/2010/05/java-vs-f.html

I think that is not "high performance" by any reasonable definition and this
reflects fundamental deficiencies in the VM itself, so there is no hope of
working around it in general.

I have not been able to get Bigloo to run: it was deleted from Debian and
Ubuntu (and the shootout) and the source distribution barfs during
configuration with " ./install-gc-7.1: 39: patch: not found".

> It may just end up that we have different perceptions of "high
> performance", and of the trade-offs we are going to make in our
> language / platform choices.

Probably. What languages do not you not consider to be high performance?

Cheers,
Jon.

RE: [Caml-list] about OcamIL

[forum]

Jon Harrop <jonathandeanharrop@googlemail.com> a écrit :

(...)

> I don't think this is heated at all. We were talking about "high
> performance" languages and you cited a bunch of languages that get whipped
> by Python on this benchmark:
>
>
> http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.
> html

Acknowledged.
"Whipped" is here 2 times slower on that particular benchmark,
while Python is rarely within an order of magnitude of OCaml code
(cf. the language shootout).
Moreover, hashtables are ubiquitous in Python (and hence probably
particularly optimized), while they are not so common in Haskell
or Caml.


>> And I still wait for a clear statement of your level for "high
>> performance",
>
> Within 2x of ANSI C compiled with gcc on all practically-relevant benchmarks
> without dropping to low-level code, e.g. GHC's FFI in Haskell.
>
>> and references to benchmarks that back up your claims in this thread.
>
>   http://fsharpnews.blogspot.com/2010/05/java-vs-f.html

Point taken.
Just notice that the 17x factor is observed on the micro-benchmark,
while on the larger one the two platforms seem on par.

Here is a question about the micro-benchmark: do you know if F# do
monomorphize the collection in this example ?
If it turns out to be done, one may probably argue that the problem
is more related to the language than to the platform (just recycling
an objection made on the page you pointed out).


>> As you seem to come from an academic background, I expect facts
>> and references, and not ad hominem attacks and fuzzy unbacked claims.
>
> An ad-hominem attack is an attack against a person. I attacked your
> examples, not you.

I do not understand how "name droping is more than silly" could be seen
as targeted at the sentence rather than at the one pronouncing it.
But, anyway, let's move to the point.


>> Unless you show that neither Bigloo nor Scala meet your (to be defined)
>> criteria for "high performance", my counterexamples still stand.
>
> Are you talking about Bigloo.NET and Scala.NET or have you gone back to the
> original discussion about JVM-based languages?
>
> Scala on the JVM is 7x slower than C++ on this benchmark:
>
>
> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scala&lan
> g2=gpp

Agreed, but it seems that if you aggregate the results of the different
benchmarks, Scala is on average only 1.5x from C++ (but far away in terms
of memory consumption). The 7x factor is observed the worst result,
the median being 2x.


(...)

>> It may just end up that we have different perceptions of "high
>> performance", and of the trade-offs we are going to make in our
>> language / platform choices.
>
> Probably. What languages do not you not consider to be high performance?

I am not sure it is that easy to compare languages, but measuring compiler
performances: any compiler that produces code that runs within -let's say- 5x
of the fastest one around, on a bunch of wide-spectrum benchmarks (e. g.
numerical code *plus* string matching *plus* tree walking, etc).
Maybe it should also be mentioned that I am more versed into symbolic  
computations.

Regarding trade-offs, I am also inclined to favor Open Source solutions and
higher-level languages (the trade-off being here execution time vs
programming/debugging time).


Xavier Clerc

PS: as an aside, I used the word "references" for academic publications that
went through a reviewing process, not blog entries.

Re: about OcamIL

[Michael Ekstrand]

On 05/19/2010 03:46 AM, forum@x9c.fr wrote:
> Jon Harrop <jonathandeanharrop@googlemail.com> a écrit :
> 
> (...)
> 
>> I don't think this is heated at all. We were talking about "high 
>> performance" languages and you cited a bunch of languages that get 
>> whipped by Python on this benchmark:
>>  
>> http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.html
>>
> 
> Acknowledged. "Whipped" is here 2 times slower on that particular
> benchmark, while Python is rarely within an order of magnitude of
> OCaml code (cf. the language shootout). Moreover, hashtables are
> ubiquitous in Python (and hence probably particularly optimized),
> while they are not so common in Haskell or Caml.

Yes, Python's hash tables are particularly optimized due to their wide
pervasive usage.  When you're testing Python hash tables, you're really
testing a carefully-written, thoroughly-tuned C implementation of hash
tables.

- Michael

Re: [Caml-list] Re: about OcamIL

[Eray Ozkural]

On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand <michael@elehack.net> wrote:
>
> Yes, Python's hash tables are particularly optimized due to their wide
> pervasive usage.  When you're testing Python hash tables, you're really
> testing a carefully-written, thoroughly-tuned C implementation of hash
> tables.

The most amusing benchmarks are those with Java bytecode working on
integer/float arrays. That is one place where Java has some admissible
performance (comparable to ocaml bytecode?), but when you go to an
algorithm that is more expensive than O(n) in time and makes more than
O(n) dynamic memory allocations you will see how miserably Java fails.
I unfortunately haven''t prepared any benchmarks for those, the
info-retrieval, data mining and 3d-engine codes I had written in Java,
well it would have been 10x-20x better if I had written them in C++
and a benchmark would be possible, but if anyone is interested I can
surely post one of those codes, a clustering algorithm for Weka for
instance. I suspect that the performance hit is a "feature" of JVM
design, in addition to the Java language design.

On the other hand, Jon's notion of high performance is valid I think.
You want to be as close to the metal as possible. Otherwise there is
no point in, say, writing a parallel version of the code. In the past
we thought that was only possible with C and Fortran. Nowadays we
think of C++ when we say that but I gladly find that ocaml is on par
with any of those for real world tasks, without requiring tedious and
cumbersome optimizations just to get it running (like in Java).

That being said, I think getting anything to run on JVM is a
remarkable achievement! It would have been so cool to be able to run
ocaml code inside a web browser. :) There are unfortunately few
alternatives for running code inside a browser.

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

RE: [Caml-list] Re: about OcamIL

[David Allsopp]

Eray Ozkural wrote:
> On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand <michael@elehack.net>
> wrote:
> >
> > Yes, Python's hash tables are particularly optimized due to their wide
> > pervasive usage.  When you're testing Python hash tables, you're
> > really testing a carefully-written, thoroughly-tuned C implementation
> > of hash tables.

<snip>

> That being said, I think getting anything to run on JVM is a remarkable
> achievement! It would have been so cool to be able to run ocaml code
> inside a web browser. :) There are unfortunately few alternatives for
> running code inside a browser.

There are two pretty viable alternatives for running OCaml code in a web
browser - ocamljs[1] is a JavaScript backend for ocamlopt and O'Browser[2]
which is a JavaScript implementation of the OCaml bytecode interpreter (or
VM, as it's been called in this thread).


David

[1] http://code.google.com/p/ocamljs
[2] http://www.pps.jussieu.fr/~canou/obrowser/tutorial

Re: [Caml-list] Re: about OcamIL

[Erick Tryzelaar]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Wed, May 19, 2010 at 6:35 AM, David Allsopp <dra-news@metastack.com>wrote:

>
> There are two pretty viable alternatives for running OCaml code in a web
> browser - ocamljs[1] is a JavaScript backend for ocamlopt and O'Browser[2]
> which is a JavaScript implementation of the OCaml bytecode interpreter (or
> VM, as it's been called in this thread).
>
> There's also nacl-ocaml [1] that uses google's native client to directly
execute native ocaml.

[1]: http://code.google.com/p/nacl-ocaml

[-- Attachment #2: Type: text/html, Size: 991 bytes --]

Re: [Caml-list] Re: about OcamIL

[Goswin von Brederlow]

"David Allsopp" <dra-news@metastack.com> writes:

> Eray Ozkural wrote:
>> On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand <michael@elehack.net>
>> wrote:
>> >
>> > Yes, Python's hash tables are particularly optimized due to their wide
>> > pervasive usage.  When you're testing Python hash tables, you're
>> > really testing a carefully-written, thoroughly-tuned C implementation
>> > of hash tables.
>
> <snip>
>
>> That being said, I think getting anything to run on JVM is a remarkable
>> achievement! It would have been so cool to be able to run ocaml code
>> inside a web browser. :) There are unfortunately few alternatives for
>> running code inside a browser.
>
> There are two pretty viable alternatives for running OCaml code in a web
> browser - ocamljs[1] is a JavaScript backend for ocamlopt and O'Browser[2]
> which is a JavaScript implementation of the OCaml bytecode interpreter (or
> VM, as it's been called in this thread).
>
>
> David
>
> [1] http://code.google.com/p/ocamljs
> [2] http://www.pps.jussieu.fr/~canou/obrowser/tutorial

Or NaCl I think it wascalled. Someone mentioned that some time ago here.

MfG
        Goswin

Re: [Caml-list] Re: about OcamIL

[Goswin von Brederlow]

Eray Ozkural <examachine@gmail.com> writes:

> On the other hand, Jon's notion of high performance is valid I think.
> You want to be as close to the metal as possible. Otherwise there is
> no point in, say, writing a parallel version of the code. In the past
> we thought that was only possible with C and Fortran. Nowadays we
> think of C++ when we say that but I gladly find that ocaml is on par
> with any of those for real world tasks, without requiring tedious and
> cumbersome optimizations just to get it running (like in Java).

The thing about ocaml is that it does not optimize. You get what you
tell it to do. You put garbage in you get garbage out. You improve your
algorithm you get a huge speedup. You don't get sudden and unexpected
side effects that magically double your speed when you add a useless
line of code somewhere because suddenly the compiler sees an
optimization.

Ocaml also finds a lot more bugs due to its stronger types and has much
nicer look&feel for many problems imho. So you get your code written
faster, looking better, working right and still have fun.

If I finished writing a program (in basically any language) and find it
runs too slow I have two avenues to optimize it:

1) Think of some algortihm that is more clever. That can easily improve
performance by magnitudes.

2) Locate the part that sucks up all the time for no work being done and
write some C/asm stubs that are specifically optimized. Except for
extrem cases this tends to give little improvement.

But that might be just me.

MfG
        Goswin

RE: [Caml-list] about OcamIL

[Jon Harrop]

Xavier Clerc wrote:
> Jon Harrop <jonathandeanharrop@googlemail.com> a écrit :
> > I don't think this is heated at all. We were talking about "high
> > performance" languages and you cited a bunch of languages that get
> whipped
> > by Python on this benchmark:
> >
> >
> > http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-
> hash-table.
> > html
> 
> Acknowledged.
> "Whipped" is here 2 times slower on that particular benchmark,
> while Python is rarely within an order of magnitude of OCaml code
> (cf. the language shootout).
> Moreover, hashtables are ubiquitous in Python (and hence probably
> particularly optimized), while they are not so common in Haskell
> or Caml.

I greatly value efficient generic collections.

> >> and references to benchmarks that back up your claims in this
> thread.
> >
> >   http://fsharpnews.blogspot.com/2010/05/java-vs-f.html
> 
> Point taken.
> Just notice that the 17x factor is observed on the micro-benchmark,
> while on the larger one the two platforms seem on par.

Sure but those two benchmarks are testing completely different things.  The
shootout's knucleotide is a larger benchmark that still uses hash tables and
Java is still 4x slower because the JVM cannot express a generic hash table
efficiently. There are many such problems where the lack of value types on
the JVM is a serious impediment to performance.

> Here is a question about the micro-benchmark: do you know if F# do
> monomorphize the collection in this example?
> If it turns out to be done, one may probably argue that the problem
> is more related to the language than to the platform (just recycling
> an objection made on the page you pointed out).

I'm not sure what you mean here. Both of the programs are just using the
generic hash table implementation native to their platform. Neither language
does anything of relevance to optimize the code. .NET is a lot faster and
uses a lot less memory than the JVM because it stores keys and values
unboxed in the spine of the hash table because they are value types whereas
the JVM boxes them, and because the insertion function is monomorphized at
JIT time.

> > Scala on the JVM is 7x slower than C++ on this benchmark:
> >
> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scal
> a&lan
> > g2=gpp
> 
> Agreed, but it seems that if you aggregate the results of the different
> benchmarks, Scala is on average only 1.5x from C++ (but far away in
> terms
> of memory consumption). The 7x factor is observed the worst result,
> the median being 2x.

Sure. This seems to be a difference in our interpretation of "high
performance". If a language or platform can be 17x slower than others then I
would not call it "high performance" even if it is competitively performant
elsewhere. Indeed, I would completely disregard averages on benchmark suites
and focus on outliers because they convey more useful information. Granted
that was a microbenchmark but the effect is severe enough to afflict many
real programs.

> >> It may just end up that we have different perceptions of "high
> >> performance", and of the trade-offs we are going to make in our
> >> language / platform choices.
> >
> > Probably. What languages do not you not consider to be high
> > performance?
> 
> I am not sure it is that easy to compare languages, but measuring
> compiler
> performances: any compiler that produces code that runs within -let's
> say- 5x
> of the fastest one around, on a bunch of wide-spectrum benchmarks (e.
> g.
> numerical code *plus* string matching *plus* tree walking, etc).
> Maybe it should also be mentioned that I am more versed into symbolic
> computations.

Then you're probably more interested in OCaml's GC vs parallelism when
performance is important.

> Regarding trade-offs, I am also inclined to favor Open Source solutions
> and
> higher-level languages (the trade-off being here execution time vs
> programming/debugging time).

I agree in general, of course, but I'm not sure "higher-level languages"
means much in this context. Is C# higher level than Java? Maybe, but I'm
interested in the value types and approach to generics here.

Monomorphization and unboxed tuples get you a long way towards decent
performance without a top-notch GC tuned for functional languages. That
makes it feasible to implement with a naïve multicore-capable GC, which is
precisely the current direction of HLVM.

> PS: as an aside, I used the word "references" for academic publications
> that went through a reviewing process, not blog entries.

I see. I value reproducible results far higher than peer reviewed academic
papers, particularly in this context.

Cheers,
Jon.

RE: [Caml-list] about OcamIL

[Ed Keith]

--- On Fri, 5/14/10, Jon Harrop <jonathandeanharrop@googlemail.com> wrote:

> From: Jon Harrop <jonathandeanharrop@googlemail.com>
> Subject: RE: [Caml-list] about OcamIL
> To: caml-list@yquem.inria.fr
> Date: Friday, May 14, 2010, 6:40 AM
> Xavier Clerc wrote:
> > Limiting myself to the JVM...
> > Moreover, at least Scala and Bigloo deliver excellent
> performances.
> 
> I have benchmarks where the JVM is well over 10x slower
> than .NET. So I do
> not regard any JVM-based language as "high performance".

I have never used it, but I believe Scala works with .NET.

    -EdK

Ed Keith
e_d_k@yahoo.com

Blog: edkeith.blogspot.com






      

Re: [Caml-list] about OcamIL

[Goswin von Brederlow]

Jon Harrop <jonathandeanharrop@googlemail.com> writes:

> Xavier Clerc wrote:
>> Limiting myself to the JVM...
>> Moreover, at least Scala and Bigloo deliver excellent performances.
>
> I have benchmarks where the JVM is well over 10x slower than .NET. So I do
> not regard any JVM-based language as "high performance".
>
> Cheers,
> Jon.

You can pretty much write a benchmark for any 2 languages that
specifically targets the weekness of one and the strength of the other
showing that one is better than the other by a wide margin. You can
usualy reverse the argument with a different benchmark.

So your argument as such says nothing about JVM, just something about
your benchmarks.

MfG
       Goswin

Re: [Caml-list] about OcamIL

[ben kuin]

> So your argument as such says nothing about JVM
jon-bot: yes it does, look at those numbers here: ...
goswin-bot: no it doesn't because: ... startup time ... hotspot ... server
...
jon-bot: moron
goswin-bot: liar

So far the typical java-shootout pattern.

Maybe another approach would be to compare the JVM and the CLR in the
realworld. I think it's interesting that on the ms-windows platform
.net is used for everything with great success:
- desktop apps (mostly .net: windows forms, wpf / c++ is dying)
- web apps (mostly .net: asp.net / asp and com are dead)
- backend services (c++ and .net apis: sharepoint, ... / dcom is dying)

Compared to that I think the jvm is only succesful when it comes to
'backend services', which often play an important role in big and
often technically conservative companies.
 There are (great) desktop and web apps in java but they require much
more expertise then the clr equivalent, they are fewer and often more
expensive. That means on the linux platform we have the following
situation:
- desktop apps (highly fragmented/diversified)
- web apps (highly fragmented/diversified)
- backend services (c++ and jvm)

I think it's safe to say that on the linux platform we have NOTHING
COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't
java doesn't fill this gap? My guess is that:

   For desktop and also web apps startup time, memory usage and ease
of deployment are too important that most developers are happy with
the compromises that the jvm offers. So they do :
- use php, ruby, perl, python even for huge applications (without
typechecking at compiletime)
- write all sorts of extensions in c to speed up: XS, cython, ... (yuck)
- write all sorts of bindings to c libraries: PyGtk, ... (yuck)

With the result of fragile desktop apps and bad scaling web apps and
the consequence that we use a lot of time of hack around those
problems. I think something like the clr would be a huge progress
first and foremost for the linux programmers. Maybe Ocaml could play
an important role of providing a slick api, because of its strength
when it comes to language implementation (compilers), so we would
have:

gil ( gnu intermediate language, a bytecode )
gilrt ( gnu intermediate language runtime, a jit based vm)

- the gilrt written in c or c++
- an Ocaml binding to the gilrt
- different language implementations gPython, gRuby, gC, gJava
(Language to gil compilers written in Ocaml)

Or maybe that's just crazy talk ...
ben



-









On Fri, May 14, 2010 at 5:17 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Jon Harrop <jonathandeanharrop@googlemail.com> writes:
>
>> Xavier Clerc wrote:
>>> Limiting myself to the JVM...
>>> Moreover, at least Scala and Bigloo deliver excellent performances.
>>
>> I have benchmarks where the JVM is well over 10x slower than .NET. So I do
>> not regard any JVM-based language as "high performance".
>>
>> Cheers,
>> Jon.
>
> You can pretty much write a benchmark for any 2 languages that
> specifically targets the weekness of one and the strength of the other
> showing that one is better than the other by a wide margin. You can
> usualy reverse the argument with a different benchmark.
>
> So your argument as such says nothing about JVM, just something about
> your benchmarks.
>
> MfG
>       Goswin
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] about OcamIL

[Vincent Aravantinos]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]


Le 14 mai 10 à 18:26, ben kuin a écrit :

> I think something like the clr would be a huge progress
> first and foremost for the linux programmers. Maybe Ocaml could play
> an important role of providing a slick api, because of its strength
> when it comes to language implementation (compilers), so we would
> have:
>
> gil ( gnu intermediate language, a bytecode )
> gilrt ( gnu intermediate language runtime, a jit based vm)
>
> - the gilrt written in c or c++
> - an Ocaml binding to the gilrt
> - different language implementations gPython, gRuby, gC, gJava
> (Language to gil compilers written in Ocaml)
>
> Or maybe that's just crazy talk ...
> ben

Isn't this precisely the aim of Jon's hlvm (www.ffconsultancy.com/ocaml/hlvm/)?

V.

[-- Attachment #2: Type: text/html, Size: 1715 bytes --]

Re: [Caml-list] about OcamIL

[ben kuin]

> Isn't this precisely the aim of Jon's hlvm
> (www.ffconsultancy.com/ocaml/hlvm/)?

that's an interesting question, Here are a few thoughts:

technical:
- in .NET everything is easy (from the surface): you have your source
file (hello.cs) you take your compiler (cs.exe) and compile it to a
msil bytecode file (hello.dll). You can run reflection tools to
hello.dll or link it to a exe or generate back to source.  This
bytecodefile is your friend. You can run it on a bunch of runtimes
like .net clr, or on mono, or rotor, or dotgnu. You can register
libraries in a container to prevent versioning problems with future
releases. I couldn't figure out those equivalents int hlvm or llvm.

- with HLVM things are complex (for me): What is the role of the big
underlying llvm infrastructure. Why do even need hlvm if we have llvm
plus ocaml bindings. Does hlvm has its own bytecode? If yes where is
it specified? Is hlvm a ocaml library or is it a free standing vm?
etc.

Maybe for you these a trivial questions, but I still dont get it,
while with .net I never had problem to get the idea.


licensing:
Hlvm is driven by a company and its landing page is on a companies
website and one of its protagonists is smart *and* business savvy.
What if hlvm would really take off, could they set it free and move
the homepage to sourceforge ? Right now it's bsd licensed, maybe
tomorow it's dual licenced like Qi? Or maybe the license some (future)
killer features under a closed license?
This is just guessing - I don't want to spread fud. But as a former
.net developer I followed mono from the beginning and I'm very
disappointed that mono is still not considered as a friendly linux
citicen. All because of some half-clear license issues.

But sure hlvm is impressive and could be the solution.

Re: about OcamIL

[Sylvain Le Gall]

On 14-05-2010, ben kuin <benkuin@gmail.com> wrote:
>> Isn't this precisely the aim of Jon's hlvm
>> (www.ffconsultancy.com/ocaml/hlvm/)?
>
>
> licensing:
> Hlvm is driven by a company and its landing page is on a companies
> website and one of its protagonists is smart *and* business savvy.
> What if hlvm would really take off, could they set it free and move
> the homepage to sourceforge ?

Last time, I checked hlvm homepage was here:
http://hlvm.forge.ocamlcore.org

What difference will it make to set it on sourceforge?

The reasoning you apply to a possible change of license can be applied
to a lot of thing in Open Source World...

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: about OcamIL

[Vincent Aravantinos]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]


Le 14 mai 10 à 23:28, Sylvain Le Gall a écrit :

> On 14-05-2010, ben kuin <benkuin@gmail.com> wrote:
>>> Isn't this precisely the aim of Jon's hlvm
>>> (www.ffconsultancy.com/ocaml/hlvm/)?
>>
>>
>> licensing:
>> Hlvm is driven by a company and its landing page is on a companies
>> website and one of its protagonists is smart *and* business savvy.
>> What if hlvm would really take off, could they set it free and move
>> the homepage to sourceforge ?
>
> Last time, I checked hlvm homepage was here:
> http://hlvm.forge.ocamlcore.org
>
> What difference will it make to set it on sourceforge?
>
> The reasoning you apply to a possible change of license can be applied
> to a lot of thing in Open Source World...

My mistake: I've put the link on ffconsultancy.com instead of the  
official one on ocamlcore.

[-- Attachment #2: Type: text/html, Size: 2226 bytes --]

Re: [Caml-list] Re: about OcamIL

[ben kuin]

sylvain, between the lines I think you're say I'm overreacting. I
would put it the other way around and say it's sad when people aren't
aware of such "details".

Once I've tried my luck with the D language, just to give another
tragic example. I think if its inventor walter bright settled all
those subtle licensing issues earlier, the language had a much bigger
following today. Now it's too late.

In case of mono I think they should have rigorously abandon *all* the
non-ecma parts (ado.net, windows.forms, asp.net,...) from the start.
And the special agreement "non-lawsuit" whatever agreement between
novell and microsoft was the nail in the coffin for mono as the
standard vm on linux. The ship has sailed.

It's really sad if see when great achievements can't unfold its
potential because of such minor issues. Programming environments on
linux are particulary delicate in this regard especially because there
are so many community-focused languages today such as Python. I don't
think something closed like the JVM had the slightest chance today to
take off. The alternatives aren't bad enough anymore.

Maybe I care for hlvm too much :-)

On Fri, May 14, 2010 at 11:28 PM, Sylvain Le Gall <sylvain@le-gall.net> wrote:
> On 14-05-2010, ben kuin <benkuin@gmail.com> wrote:
>>> Isn't this precisely the aim of Jon's hlvm
>>> (www.ffconsultancy.com/ocaml/hlvm/)?
>>
>>
>> licensing:
>> Hlvm is driven by a company and its landing page is on a companies
>> website and one of its protagonists is smart *and* business savvy.
>> What if hlvm would really take off, could they set it free and move
>> the homepage to sourceforge ?
>
> Last time, I checked hlvm homepage was here:
> http://hlvm.forge.ocamlcore.org
>
> What difference will it make to set it on sourceforge?
>
> The reasoning you apply to a possible change of license can be applied
> to a lot of thing in Open Source World...
>
> Regards,
> Sylvain Le Gall
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

RE: [Caml-list] about OcamIL

[Jon Harrop]

Ben Kuin wrote:
> technical:
> - in .NET everything is easy (from the surface): you have your source
> file (hello.cs) you take your compiler (cs.exe) and compile it to a
> msil bytecode file (hello.dll). You can run reflection tools to
> hello.dll or link it to a exe or generate back to source.  This
> bytecodefile is your friend. You can run it on a bunch of runtimes
> like .net clr, or on mono, or rotor, or dotgnu. You can register
> libraries in a container to prevent versioning problems with future
> releases. I couldn't figure out those equivalents int hlvm or llvm.

They haven't been written yet. :-)

> - with HLVM things are complex (for me): What is the role of the big
> underlying llvm infrastructure.

LLVM provides the compilation to native code, both static and JIT.

> Why do even need hlvm if we have llvm plus ocaml bindings.

LLVM's intermediate representation is a low-level assembly language with no
memory safety and no automatic memory management. HLVM is a layer on top of
LLVM that provides a higher-level intermediate language that is memory safe
and garbage collected.

> Does hlvm has its own bytecode? If yes where is it specified?

HLVM's IR is evolving much too quickly to be worth specifying yet.

> Is hlvm a ocaml library or is it a free standing vm?

Today, HLVM is an OCaml library. In the future, HLVM will be a free standing
VM.

> Maybe for you these a trivial questions, but I still dont get it,
> while with .net I never had problem to get the idea.

Ultimately, HLVM should be just as easy to understand. The only reason it
appears complicated today is that HLVM is a set of evolving fragments that
are gradually stabilizing and being pulled together to form a progressively
more capable core VM.

> What if hlvm would really take off, could they set it free and move the
homepage to sourceforge?

HLVM is free. I would always keep the core (VM and standard library) open
source. I might write an "HLVM for Scientists" book, sell libraries or
implement features for a fee but nothing evil. :-)

In fact, one dream I have is to create a commerce-friendly platform for
tools and libraries. I think Linux has really suffered from being
anti-commerce rather than truly free.

Cheers,
Jon.

Re: [Caml-list] about OcamIL

[Raoul Duke]

On Fri, May 14, 2010 at 9:26 AM, ben kuin <benkuin@gmail.com> wrote:
> realworld. I think it's interesting that on the ms-windows platform
> .net is used for everything with great success:
> Compared to that I think the jvm is only succesful when it comes to
> 'backend services', which often play an important role in big and
> often technically conservative companies.
> I think it's safe to say that on the linux platform we have NOTHING
> COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't
> java doesn't fill this gap?

ms windows is a more closed and constrained and well-defined ecosystem
than linux is. i think that has impact on the situation.

sincerely.

Re: [Caml-list] about OcamIL

[ben kuin]

but that would be the big benefit of a clr like vm: It doesn't matter
how messed up, chaotic or just heterogen the environment is as long as
you can count on a regular execution of your portable bytecode.

On Fri, May 14, 2010 at 8:11 PM, Raoul Duke <raould@gmail.com> wrote:
> On Fri, May 14, 2010 at 9:26 AM, ben kuin <benkuin@gmail.com> wrote:
>> realworld. I think it's interesting that on the ms-windows platform
>> .net is used for everything with great success:
>> Compared to that I think the jvm is only succesful when it comes to
>> 'backend services', which often play an important role in big and
>> often technically conservative companies.
>> I think it's safe to say that on the linux platform we have NOTHING
>> COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't
>> java doesn't fill this gap?
>
> ms windows is a more closed and constrained and well-defined ecosystem
> than linux is. i think that has impact on the situation.
>
> sincerely.
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Fwd: [Caml-list] about OcamIL

[Raoul Duke]

---------- Forwarded message ----------
From: Raoul Duke <raould@gmail.com>
Date: Fri, May 14, 2010 at 2:42 PM
Subject: Re: [Caml-list] about OcamIL
To: ben kuin <benkuin@gmail.com>


On Fri, May 14, 2010 at 11:59 AM, ben kuin <benkuin@gmail.com> wrote:
> but that would be the big benefit of a clr like vm: It doesn't matter
> how messed up, chaotic or just heterogen the environment is as long as
> you can count on a regular execution of your portable bytecode.

of course it matters: there must be the resources to get the vm ported
across all the fubar variations of the ecosystem. the combinatorics
has to be dealt with somewhere. that kind of complexity is less in the
hegemonic windows os world, i hypothesize.

sincerely.

Re: [Caml-list] about OcamIL

[Vincent Aravantinos]

Le 14 mai 10 à 23:42, Raoul Duke a écrit :

> ---------- Forwarded message ----------
> From: Raoul Duke <raould@gmail.com>
> Date: Fri, May 14, 2010 at 2:42 PM
> Subject: Re: [Caml-list] about OcamIL
> To: ben kuin <benkuin@gmail.com>
>
>
> On Fri, May 14, 2010 at 11:59 AM, ben kuin <benkuin@gmail.com> wrote:
>> but that would be the big benefit of a clr like vm: It doesn't matter
>> how messed up, chaotic or just heterogen the environment is as long  
>> as
>> you can count on a regular execution of your portable bytecode.
>
> of course it matters: there must be the resources to get the vm ported
> across all the fubar variations of the ecosystem. the combinatorics
> has to be dealt with somewhere. that kind of complexity is less in the
> hegemonic windows os world, i hypothesize.

Please. You're not talking about the same thing. Ben talks about the  
benefits such a vm would have once it would be done, you talk about  
how hard it would be to do it.

Re: [Caml-list] about OcamIL

[Raoul Duke]

> Please. You're not talking about the same thing. Ben talks about the
> benefits such a vm would have once it would be done, you talk about how hard
> it would be to do it.

i think several things are being intertwined here, i don't agree with
you evaluation of the discussion.

sincerely.

Re: [Caml-list] about OcamIL

[ben kuin]

> Please. You're not talking about the same thing. Ben talks about the
> benefits such a vm would have once it would be done, you talk about how hard
> it would be to do it.

Exactly, thanks.

I assume it's save to say that most today (business) critical
applications have to be written in a vm supported language. What is
with Ocamls vm then?
I have the impression that only little development is going into
Ocamls vm. Or is that wrong? If no - what is the reason for this? What
if ocamlopt would be dropped for a faster ocaml vm? Would that be an
option?

Re: [Caml-list] about OcamIL

[Erik de Castro Lopo]

ben kuin wrote:

> I assume it's save to say that most today (business) critical
> applications have to be written in a vm supported language.

Why do you assume that?

The only evidence to support this is the widespead usage of
Java and C#, but I think that is a language choice rather than
a conscious decision to use a language that runs on a VM.

People chose Java and C# because they are preferable to
fundamentally unsafe langauges like C and C++.

> What if ocamlopt would be dropped for a faster ocaml vm?

Why? Even if the Ocaml was able to target a faster VM, there
are still many people who would chose to generate native
binaries.

Erik (who uses Ocaml compiled to native binaries for mission
critical code)
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: [Caml-list] about OcamIL

[Goswin von Brederlow]

Erik de Castro Lopo <mle+ocaml@mega-nerd.com> writes:

> ben kuin wrote:
>
>> I assume it's save to say that most today (business) critical
>> applications have to be written in a vm supported language.

Hardly any business today has an inhomogene environment. And if the
environment is homogene then the vm gives you 0 advantage. It just costs
you overhead to emulate.

MfG
        Goswin

RE: [Caml-list] about OcamIL

[Jon Harrop]

Goswin wrote:
> Hardly any business today has an inhomogene environment. And if the
> environment is homogene then the vm gives you 0 advantage. It just
> costs you overhead to emulate.

A Common Language Runtime (CLR) is an obvious counter example => the shared
VM gives you safe and high-level interoperability between languages. For
example, you can pass garbage collected data structures between languages by
reference because they share a single GC. Without a CLR, you generally
resort to painstakingly copying everything for no reason and give up for
anything non-trivial (like closures) and often end up with segmentation
faults and no working code.

I was once asked how someone might interoperate between Standard ML and
OCaml (two very closely related languages) and my answer was XMLRPC.
Contrast that with F# development where almost every program in existence
relies entirely upon seamless two-way interoperability with C# libraries
like WPF.

Cheers,
Jon.

Re: [Caml-list] about OcamIL

[Goswin von Brederlow]

Jon Harrop <jonathandeanharrop@googlemail.com> writes:

> Goswin wrote:
>> Hardly any business today has an inhomogene environment. And if the
>> environment is homogene then the vm gives you 0 advantage. It just
>> costs you overhead to emulate.
>
> A Common Language Runtime (CLR) is an obvious counter example => the shared
> VM gives you safe and high-level interoperability between languages. For
> example, you can pass garbage collected data structures between languages by
> reference because they share a single GC. Without a CLR, you generally
> resort to painstakingly copying everything for no reason and give up for
> anything non-trivial (like closures) and often end up with segmentation
> faults and no working code.

And there we disagree. A VM does not give you savety or high-level
anything in general. A VM can be as unsafe and low-level as you
like. Most VMs won't stop you when you write an int to some (allocated)
memory address and load a float from the same address. And BANG you have
total garbage. Most VMs won't catch array/string over/underruns. And so
on. The safety usualy comes from the high-level language used on top of
the VM.

As for interoperability you get the same if you define your CLR to be
native mode with ONE specific GC. You still need to port every single
languag you use to that CLR, native or VM.

> I was once asked how someone might interoperate between Standard ML and
> OCaml (two very closely related languages) and my answer was XMLRPC.
> Contrast that with F# development where almost every program in existence
> relies entirely upon seamless two-way interoperability with C# libraries
> like WPF.

And how do I get the F# code to use my haskell lib?

The interoperability comes from F# and C# having common grounds. Not
from them running in a VM. The common language runtime is the key there.

> Cheers,
> Jon.

MfG
        Goswin

PS: There is a java CPU so java bytecode can run native. I wonder when
someone will build a F# cpu.

Re: [Caml-list] about OcamIL

[ben kuin]

hi erik,
I highly appreciate your blog, so it hurts me a little but - I disagree:

> The only evidence to support this is the widespead usage of
> Java and C#, but I think that is a language choice rather than
> a conscious decision to use a language that runs on a VM.
>
> People chose Java and C# because they are preferable to
> fundamentally unsafe langauges like C and C++.

English is not my first language, maybe I misunderstand, but what
you're are saying here sound like a complete contradiction to me:
Like you say C and C++ are considered as 'unsafe' languages. But thats
because they offer features, that are not available when programming
for a vm. This has nothing to do with languages, it's a conscious
platform decision.

>> What if ocamlopt would be dropped for a faster ocaml vm?
>
> Why? Even if the Ocaml was able to target a faster VM, there
> are still many people who would chose to generate native
> binaries.

I'd call that a questionable decision. As far as I know, using native
binaries means to open a whole range of potentially uncorrectionable
problems with abi incomptabilities between libraries or with changes
of the underlying os.

As far as I know when you go native you always have to take abi
incompatibility and therefore recompilation into account. For business
apps, that's a showstopper.

> Erik (who uses Ocaml compiled to native binaries for mission
> critical code)

Would you mind to share some infos about your experiences, maybe on your blog?

Re: [Caml-list] about OcamIL

[Ed Keith]

--- On Sat, 5/15/10, ben kuin <benkuin@gmail.com> wrote:

> >> What if ocamlopt would be dropped for a faster
> ocaml vm?
> >
> > Why? Even if the Ocaml was able to target a faster VM,
> there
> > are still many people who would chose to generate
> native
> > binaries.
> 
> I'd call that a questionable decision. As far as I know,
> using native
> binaries means to open a whole range of potentially
> uncorrectionable
> problems with abi incomptabilities between libraries or
> with changes
> of the underlying os.
> 
> As far as I know when you go native you always have to take
> abi
> incompatibility and therefore recompilation into account.
> For business
> apps, that's a showstopper.

I have worked in many environments, most have been homogeneous, none have had more then four platforms. Supporting four platforms is not difficult if your tools support all four platforms (unfortunately Ocaml's support for Windows is a bit spotty). Running a VM, no matter how good, is always going to carry a performance hit. If your code is UI intensive, that may be acceptable (although I find the startup time for the JVM to be a problem), but if your code is memory or CPU intensive a VM may be unaceptable.

   -EdK

Ed Keith
e_d_k@yahoo.com

Blog: edkeith.blogspot.com





      

Re: [Caml-list] about OcamIL

[Vincent Aravantinos]

Le 15 mai 10 à 11:45, ben kuin a écrit :

>>> What if ocamlopt would be dropped for a faster ocaml vm?
>>
>> Why? Even if the Ocaml was able to target a faster VM, there
>> are still many people who would chose to generate native
>> binaries.
>
> I'd call that a questionable decision. As far as I know, using native
> binaries means to open a whole range of potentially uncorrectionable
> problems with abi incomptabilities between libraries or with changes
> of the underlying os.
>
> As far as I know when you go native you always have to take abi
> incompatibility and therefore recompilation into account. For business
> apps, that's a showstopper.

Aren't most Windows applications binary ones?
Not all Windows apps are .Net based, or run on a whatever vm.
Most others are binary, aren't they?

If yes it seems this has not been a big showstopper to Windows apps  
developpers...

Maybe I don't get the precise sense of "binary".

V.

Re: [Caml-list] about OcamIL

[ben kuin]

> If yes it seems this has not been a big showstopper to Windows apps

err what?? On what planet do you live? It must be a nice place :-)

COM components ( to encapsulate the abi )
DLL hell ( never heard of that? com registration)
STL ( taming the abi)
CORBA ( to talk between incompatible libraries)
VC6++, VC7++ incompatibilities


If you really want to torture a developer, these is the best toolset
you get. If you want to punish the user with crashing apps and
beautiful error messages ( stuff like: "Error msxml.dll not registered
by regsvr32" then go ahead.

.NET was already a success before the dotnet-sdk was downloadable.

Re: [Caml-list] about OcamIL

[Erik de Castro Lopo]

ben kuin wrote:

> > If yes it seems this has not been a big showstopper to Windows apps
> 
> err what?? On what planet do you live? It must be a nice place :-)

I would say it hasn't been a big problem on Windows because people
are still using windows. Furthermore, how many of the programs that
Microsoft distrubutes with Windows 7 are written in C#/.NET and 
how many are written in C++? 

Furthermore, many of the problems suffered by Windows are not a
problem on Unix systems.
 
> COM components ( to encapsulate the abi )

They were always a mistake. COM never made it to Unix.

> DLL hell ( never heard of that? com registration)

This is a Microsoft specific problem. Unix systems have used versioned
shared libraries since at least the mid 1980s.

> STL ( taming the abi)

The STL should only be problem and compile time.

> CORBA ( to talk between incompatible libraries)

Another mistake. Never common on Unix.

> VC6++, VC7++ incompatibilities

I've only ever come across one problem as a result of this, a problem
with passing file descriptor across the application/DLL boundary when
the application and the DLL were compiled with different versions of
the compiler. Again, this is a problem with Microsoft's OS that I have
never come across on any of the Unix systems I have used.

> If you really want to torture a developer, these is the best toolset
> you get.

You have to be kidding me. I personally think the Microsoft development
tools are completely horrible.

> If you want to punish the user with crashing apps and
> beautiful error messages ( stuff like: "Error msxml.dll not registered
> by regsvr32" then go ahead.

How does that have anything to do with using a VM or not.
 
> .NET was already a success before the dotnet-sdk was downloadable.

Microsoft was your saviour because Microsoft caused all your problems
in the first place.

Microsoft keeps calling Unix a legacy platform, but Unix has evolved 
over time and to people running modern versions of Unix, its Windows
that looks like a legacy platform.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: [Caml-list] about OcamIL

[ben kuin]

> Microsoft was your saviour because Microsoft caused all your problems
> in the first place.

Ok, the topic here is personal and office computing. I mean cubical
drones who are not allowed to used right mouse button? Consultants and
their 20 MB powerpoints? Middle management assholes with the portable
devices, always busy with syncing stuff from some weird Exchange
source to another place. Grandpa who is trying to install his new
scanner which also a tv receiver, because the isp told him he also
watch tv over internet?

It's one ugly amorphous quickly fluctuating mess that happens if you
endow the average end user with a PC and throw them into a hit-and-run
market environment.

So far linux was spared by the end user and 'personal computing'.
Would linux be really capable to enhance the personal computing
experience not only for the enduser but also for the developer? I see
two stumbling blocks:

- X/X11/X org:  I support a few members in my family and friends with
linux installations and problems. X is a source for a lot of grieve.
The complexity of X punches the end user to often. I dont see
alternatives though.

- Applications: I mean the way enduser application are developed
deployed and installed. The best way would be mono, unfortunately a
forbidden fruit because microsoft was too stupid to really set it
free.

Re: [Caml-list] about OcamIL

[Goswin von Brederlow]

Erik de Castro Lopo <mle+ocaml@mega-nerd.com> writes:

> ben kuin wrote:
>> If you really want to torture a developer, these is the best toolset
>> you get.
>
> You have to be kidding me. I personally think the Microsoft development
> tools are completely horrible.

That is what he said. That toolset is the best to *torture* a developer.

MfG
        Goswin

Re: [Caml-list] about OcamIL

[Goswin von Brederlow]

ben kuin <benkuin@gmail.com> writes:

> hi erik,
> I highly appreciate your blog, so it hurts me a little but - I disagree:
>
>> The only evidence to support this is the widespead usage of
>> Java and C#, but I think that is a language choice rather than
>> a conscious decision to use a language that runs on a VM.
>>
>> People chose Java and C# because they are preferable to
>> fundamentally unsafe langauges like C and C++.
>
> English is not my first language, maybe I misunderstand, but what
> you're are saying here sound like a complete contradiction to me:
> Like you say C and C++ are considered as 'unsafe' languages. But thats
> because they offer features, that are not available when programming
> for a vm. This has nothing to do with languages, it's a conscious
> platform decision.

Who says they are not available in a vm? There is nothing stopping you
from compiling C code to run on a vm. It will be just as unsafe and
crash in the vm as it is on a real cpu.

Similary ocaml can be run in a vm or native. Why would the quality be
improved by running it in a vm? Both bytecode and native use the same
source (unless you mean things like --unsafe).

>>> What if ocamlopt would be dropped for a faster ocaml vm?
>>
>> Why? Even if the Ocaml was able to target a faster VM, there
>> are still many people who would chose to generate native
>> binaries.
>
> I'd call that a questionable decision. As far as I know, using native
> binaries means to open a whole range of potentially uncorrectionable
> problems with abi incomptabilities between libraries or with changes
> of the underlying os.
>
> As far as I know when you go native you always have to take abi
> incompatibility and therefore recompilation into account. For business
> apps, that's a showstopper.

Has the native ABI ever changed in ocaml native code? I somewhat doubt
that. That is just the C ABI. The compiled module interface though
changes with every compiler version and every source change it seems. So
every time you update the compiler or change a module you need to
recompile everything.

But that is a problem of the specific ocaml implementation and in no way
a general problem.

And correct me if I'm wrong but don't you have to recompile bytecode
just as well every time you update the compiler?

>> Erik (who uses Ocaml compiled to native binaries for mission
>> critical code)
>
> Would you mind to share some infos about your experiences, maybe on your blog?

MfG
        Goswin

Re: [Caml-list] about OcamIL

[Erik de Castro Lopo]

ben kuin wrote:

> English is not my first language, maybe I misunderstand, but what
> you're are saying here sound like a complete contradiction to me:
> Like you say C and C++ are considered as 'unsafe' languages.

Yes. One can't really program in those languages without using
pointers and manually allocating/deallocating memory.

> But thats
> because they offer features, that are not available when programming
> for a vm. This has nothing to do with languages, it's a conscious
> platform decision.

Yes, many languages (native compiled Ocaml and Haskell are just
two) have garbage collection and are fundamentally safe.
 
> I'd call that a questionable decision.

I call requiring a VM one more potential point of failure.

> As far as I know, using native
> binaries means to open a whole range of potentially uncorrectionable
> problems with abi incomptabilities between libraries or with changes
> of the underlying os.

My experience says otherwise. My experience consists of having lots of
small self contained programs, written in Ocaml and distributed using
the Debian packaging system.

Binary incompatibilities always get found during development and
developer testing and QA.

I find Ocaml native binaries far more reliable that those of C and
C++ and that reliability is due to garbage collection, and the fact
that Ocaml's type system helps prevent bugs.


> As far as I know when you go native you always have to take abi
> incompatibility and therefore recompilation into account. For business
> apps, that's a showstopper.

You have no idea just how much you are overstating the case.

> Would you mind to share some infos about your experiences, maybe on your
> blog?

There's really not much to share. Its programs written in Ocaml and
distributed to the client machines via the Debian packaging system.
 
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

RE: [Caml-list] about OcamIL

[Jon Harrop]

Raoul Duke wrote:
> On Fri, May 14, 2010 at 11:59 AM, ben kuin <benkuin@gmail.com> wrote:
> > but that would be the big benefit of a clr like vm: It doesn't matter
> > how messed up, chaotic or just heterogen the environment is as long
> > as you can count on a regular execution of your portable bytecode.
> 
> of course it matters: there must be the resources to get the vm ported
> across all the fubar variations of the ecosystem. the combinatorics
> has to be dealt with somewhere. that kind of complexity is less in the
> hegemonic windows os world, i hypothesize.

Not really. Windows supports a far wider variety of hardware than Linux and
Apple supports even less. Providing consistency was one of the major
advantages of .NET that had people building on it originally. If you want
robustly-deployable hardware-accelerated GUI apps then WPF and, therefore,
.NET is your only choice on Windows and you have zero choices on Linux. If
you wanted to build something comparable on Linux you would use OpenGL and
must then test all software/hardware combinations to see which were
unreliable (OpenGL drivers are often very unreliable on Linux).

I saw this first hand when I productized OpenGL-based presentation software
written in OCaml. It was a catastrophe: with segfaults on 80% of customers
machines that we could not reproduce. We canned it and never tried to sell
Linux-based software again.

Cheers,
Jon.

Re: [Caml-list] about OcamIL

[Erik de Castro Lopo]

Jon Harrop wrote:

> Not really. Windows supports a far wider variety of hardware than Linux and

Oh really?

I have a three machine here:

  a) A Dual PowerPC G5 Apple Mac.
  b) A SUN ultra-sparc X1.
  c) One of the early Cobalt Qube machines with a MIPS CPU.

All of these run Debian. Can windows run on these machines?

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

RE: [Caml-list] about OcamIL

[Jon Harrop]

Erik wrote:
> Jon Harrop wrote:
> > Not really. Windows supports a far wider variety of hardware than
> > Linux and
> 
> Oh really?

Yes, really.

> I have a three machine here:
> 
>   a) A Dual PowerPC G5 Apple Mac.
>   b) A SUN ultra-sparc X1.
>   c) One of the early Cobalt Qube machines with a MIPS CPU.

For every SUN Ultra-sparc or Cobalt Qube there are thousands of gadgets like
cameras and printers that don't have Linux drivers or that have only
partially-functioning Linux drivers.

Cheers,
Jon.

Re: [Caml-list] about OcamIL

[Goswin von Brederlow]

Jon Harrop <jonathandeanharrop@googlemail.com> writes:

> Erik wrote:
>> Jon Harrop wrote:
>> > Not really. Windows supports a far wider variety of hardware than
>> > Linux and
>> 
>> Oh really?
>
> Yes, really.
>
>> I have a three machine here:
>> 
>>   a) A Dual PowerPC G5 Apple Mac.
>>   b) A SUN ultra-sparc X1.
>>   c) One of the early Cobalt Qube machines with a MIPS CPU.
>
> For every SUN Ultra-sparc or Cobalt Qube there are thousands of gadgets like
> cameras and printers that don't have Linux drivers or that have only
> partially-functioning Linux drivers.
>
> Cheers,
> Jon.

Damn, my stupid proprietary webcam doesn't work. Hmpf, not .net for me
then. :)

MfG
        Goswin

Re: [Caml-list] about OcamIL

[Eray Ozkural]

On Sun, May 16, 2010 at 5:04 AM, Jon Harrop
<jonathandeanharrop@googlemail.com> wrote:
> Erik wrote:
>> Jon Harrop wrote:
>> > Not really. Windows supports a far wider variety of hardware than
>> > Linux and
>>
>> Oh really?
>
> Yes, really.

Well, this does sound a little funny considering that Linux is free
software and has been ported to almost every odd hardware platform,
and how many platforms does Windows run on?

In my opinion, the existence and market-domination of Windows is a
little like the case with fossil fuel and internal combustion engines
vs. whatever higher technology is being suppressed.

However, I can confidently say that Windows would never be a decent
operating system if there were not rivalry from free software (Linux
and BSD kernels of course!)

Cheers,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

Re: [Caml-list] about OcamIL

[ben kuin]

Erik wrote:
>>> Jon Harrop wrote:
>>> > Not really. Windows supports a far wider variety of hardware than
>>> > Linux and
>
> Well, this does sound a little funny considering that Linux is free
> software and has been ported to almost every odd hardware platform,
> and how many platforms does Windows run on?

I think he meant hardware support as support for devices/drivers.

> In my opinion, the existence and market-domination of Windows is a
> little like the case with fossil fuel and internal combustion engines
> vs. whatever higher technology is being suppressed.

> However, I can confidently say that Windows would never be a decent
> operating system if there were not rivalry from free software (Linux
> and BSD kernels of course!)

I look foreward to the day when somebody explain me why even well
educated people loose the ability to differentiate when it comes to
Microsoft, while the fall into a state of extasy everytime Google
drops a little comfort toy while they carry on with their business
venture of 'monetizing' the worlds information.

The frightening success of Googles IT Services (Postini, Google Apps)
is unfortunately not only Microsofts fault, it also the consequence of
the fact that it is impossible with linux to significantly lowering
maintaining costs of a bigger it infrastructure. In other words: It's
still too difficult to manage. That in turn is what I believe a
consequence of the lack of modern language infrastructure.

As a proof of concept, try to lower your it costs with a true open
source alternative to Exchange. See? And this is the niche Google
fills with completely aggressive pricing.

Re: [Caml-list] about OcamIL

[ben kuin]

> Or use the real ocaml on a real OS (^_^)

my vision is a unix centric clr based vm:
- no non-ecma parts
- maybe a complete different base class library (like OcamIL)
- the target is not to enable windows apps on unix, but the other way around
- the vm is crossplattform, the bytecode is compatible to mono and
ms-.net but the library is incopatible to the standard .net stack