Re: [Caml-list] Re: about OcamIL
"David Allsopp" writes: > Eray Ozkural wrote: >> On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand >> 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. > > > >> 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 ___ 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] Re: about OcamIL
Eray Ozkural 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 ___ 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] Re: about OcamIL
On Wed, May 19, 2010 at 6:35 AM, David Allsopp 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 ___ 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] Re: about OcamIL
Eray Ozkural wrote: > On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand > 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. > 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 ___ 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] Re: about OcamIL
On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand 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 ___ 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
[Caml-list] Re: about OcamIL
On 05/19/2010 03:46 AM, fo...@x9c.fr wrote: > Jon Harrop 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 ___ 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] Re: about OcamIL
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 wrote: > On 14-05-2010, ben kuin 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 > ___ 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] Re: about OcamIL
Le 14 mai 10 à 23:28, Sylvain Le Gall a écrit : On 14-05-2010, ben kuin 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.___ 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
[Caml-list] Re: about OcamIL
On 14-05-2010, ben kuin 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
[Caml-list] Re: about OcamIL
On 07-05-2010, Dmitry Bely 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. ___ 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