From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id EFA87BC57 for ; Fri, 14 May 2010 18:26:05 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngDAHcW7UtKfVK0gGdsb2JhbACRSownCBUBARQkIq1nggCFAi6ITQEBAwWCW4IwBA X-IronPort-AV: E=Sophos;i="4.53,231,1272837600"; d="scan'208";a="62838390" Received: from mail-wy0-f180.google.com ([74.125.82.180]) by mail4-smtp-sop.national.inria.fr with ESMTP; 14 May 2010 18:26:05 +0200 Received: by wyb33 with SMTP id 33so277747wyb.39 for ; Fri, 14 May 2010 09:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=m6J+IlNDopv12AhaObI/jfZe0T9X/i/J5imGIaB73Go=; b=UUaBsO96/zwcgpBhjDrvl2aRZQTlE3a/BIGsE50C3HL46ZxaYiquOPc8w9xVH+QaRt bvzMZ5t5jdcvlEfh0+d5SZHSUl3j209U/FhZVuOpMtFd1sDa5NE49rcHWBjfgXLYxUKX uCt2sqbL7lu2nGiGrNHVzlCadq8rq156mKtIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=BydATDe5W7zFXauUfRL6L21rf+/a4+aeUjbXZcw52FMfHmIibgEUVjWHqgEWuFBR+f 2YzbZD5nUDTOH/Nl7J8ZRYG5qkdNmdivAv6rOFmvM434YEFDbjA5y5Gw7uQ2EuNSlllu C8jn7jKAD6dZBU6nOeDXN6pGyMM//V3ovkvVk= MIME-Version: 1.0 Received: by 10.216.158.85 with SMTP id p63mr1061143wek.67.1273854364955; Fri, 14 May 2010 09:26:04 -0700 (PDT) Received: by 10.216.45.69 with HTTP; Fri, 14 May 2010 09:26:04 -0700 (PDT) In-Reply-To: <87fx1uh5r5.fsf@frosties.localdomain> References: <951508.20587.qm@web58708.mail.re1.yahoo.com> <201005061233.07551.peng.zang@gmail.com> <07b101caf08b$3e5022c0$baf06840$@com> <088201caf1ce$b5060cb0$1f122610$@com> <20100512151137.26894ywcpv71ixvk@imp.ovh.net> <012601caf351$e9a362e0$bcea28a0$@com> <87fx1uh5r5.fsf@frosties.localdomain> Date: Fri, 14 May 2010 18:26:04 +0200 Message-ID: Subject: Re: [Caml-list] about OcamIL From: ben kuin To: Goswin von Brederlow , caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; bindings:01 ocaml:01 bytecode:01 runtime:01 ocaml:01 bigloo:01 cheers:01 beginner's:01 bug:01 hotspot:98 sharepoint:98 slick:98 mfg:98 beginners:01 wrote:01 > 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 w= rote: > Jon Harrop 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 > =A0 =A0 =A0 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 >