From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id E6607BB84 for ; Tue, 23 Dec 2008 18:30:12 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEBACOvUEnUnw6UkWdsb2JhbACCO5EyAQEBAQkLCgcRBKs5WJFshkM X-IronPort-AV: E=Sophos;i="4.36,272,1228086000"; d="scan'208";a="20754738" Received: from fhw-relay07.plus.net ([212.159.14.148]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 23 Dec 2008 18:30:12 +0100 Received: from [87.114.38.62] (helo=leper.local) by fhw-relay07.plus.net with esmtp (Exim) id 1LFB59-0001wR-IO for caml-list@yquem.inria.fr; Tue, 23 Dec 2008 17:30:11 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] More Caml Date: Tue, 23 Dec 2008 17:33:16 +0000 User-Agent: KMail/1.9.9 References: <157727.93194.qm@web111508.mail.gq1.yahoo.com> <200812230959.24662.jon@ffconsultancy.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812231733.16915.jon@ffconsultancy.com> X-Plusnet-Relay: 7f6375075fea8a08abf0bfda41e2ab17 X-Spam: no; 0.00; afaik:01 compiler:01 ocaml:01 trade-off:01 run-time:01 compiler:01 ocaml's:01 confines:01 frog:98 wrote:01 symbolic:01 caml-list:01 computation:01 gcs:01 gcs:01 On Tuesday 23 December 2008 15:32:52 Ashish Agarwal wrote: > > a lot more effort into numerics and string processing and a lot less > > effort into symbolics. > > Is there any fundamental reason these two goals must be at odds? No theoretical reason, AFAIK. > Why can't a compiler be good at numeric and symbolic computation? The required performance characteristics appear to be mutually exclusive when it comes to GCs. Symbolics benefit enormously from extremely fast allocation rates for short-lived values and numerics benefit enormously from efficient handling of shared memory. Today's GCs either provide one or the other. OCaml is ideal for symbolics and awful for parallel programming. The CLR is awful for symbolics and good for parallel programming. The JVM is arguably the best trade-off but its run-time cannot handle tail calls, which makes it a useless for performant functional languages. In the case of the compiler I'm writing, there are more pressing practical concerns. Primarily that it is extremely difficult to write an efficient GC like OCaml's, if not impossible within the confines of LLVM (and LLVM is the only thing making this feasible for me). I believe I can get some kind of GC working, possibly even a parallel GC. Moreover, I think I can remove all (performance) overhead associated with automatic memory management from numerical routines. I think that would be very compelling even if it were bad for symbolics... -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e