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=1.7 required=5.0 tests=AWL,DNS_FROM_RFC_POST, HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id DBAB7BB84 for ; Tue, 23 Dec 2008 16:32:54 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoICAD+TUEnRVciqkGdsb2JhbACCOwMxkEE+AQEBAQkJDAcRA6sFWINTgQSMewEDAQOGQA X-IronPort-AV: E=Sophos;i="4.36,271,1228086000"; d="scan'208";a="18837425" Received: from wf-out-1314.google.com ([209.85.200.170]) by mail2-smtp-roc.national.inria.fr with ESMTP; 23 Dec 2008 16:32:53 +0100 Received: by wf-out-1314.google.com with SMTP id 24so2762629wfg.15 for ; Tue, 23 Dec 2008 07:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=mQ3a8PXjURlSfGI3hWOx1P+orO+T5D5FRIC+wa6vX+4=; b=KfeusHqoeJnlzFiK0u6G6Jx80pgCBgle9/U5FyvknebB4XlyzzUoVvNdXxKAChcxdW 3gHGwhUlc8CxMs+fh9JqwGPPv7x9egIPF0v8yJSC1AQSe5SiuhciPG5PtPezWJrFMtAx OFnYIcCaPOy3RoVHVAgEx6bHis+AI0MN8tRs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=a2dvWELjqEHvLsN7I/K92Uh8dvYgtglJVGGPdE4xzLI0NBvnUDgga1UkR2lOv6Dd9J MzmdE9o5yrEntg3vHWhiZ2fxTd4bGt3lHTh7gyh1MpwgLtkm4HvskL4TLcEKWzIa1Q6B XpYFozcgvR2TY2kw9flUofNpAmE1RPdVnaLbw= Received: by 10.142.44.11 with SMTP id r11mr3211215wfr.95.1230046372470; Tue, 23 Dec 2008 07:32:52 -0800 (PST) Received: by 10.143.93.7 with HTTP; Tue, 23 Dec 2008 07:32:52 -0800 (PST) Message-ID: Date: Tue, 23 Dec 2008 10:32:52 -0500 From: "Ashish Agarwal" To: "Jon Harrop" Subject: Re: [Caml-list] More Caml Cc: caml-list@yquem.inria.fr In-Reply-To: <200812230959.24662.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69379_31197055.1230046372462" References: <157727.93194.qm@web111508.mail.gq1.yahoo.com> <20081222214456.GA8148@annexia.org> <200812230607.37399.jon@ffconsultancy.com> <200812230959.24662.jon@ffconsultancy.com> X-Spam: no; 0.00; compiler:01 ocaml:01 afaict:01 ocaml:01 ocaml's:01 arrays:01 allocations:01 beginner's:01 bug:01 compiler:01 afaict:01 ocaml's:01 arrays:01 allocations:01 beginner's:01 ------=_Part_69379_31197055.1230046372462 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > 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? Why can't a compiler be good at numeric and symbolic computation? On Tue, Dec 23, 2008 at 4:59 AM, Jon Harrop wrote: > On Tuesday 23 December 2008 06:07:37 Jon Harrop wrote: > > Yes. I'll do a bit more work on it and then tidy it up and document it > > before uploading it, unless there is any great interest from people now. > > Incidentally, I would like to know what performance issues (good and bad) > people have with the current OCaml implementation? > > AFAICT, OCaml evolved from a family of languages that were only optimized > for > symbolic processing. Some of OCaml's relatives, like PolyML, were able to > provide even faster symbolic processing than naive C but their numerical > performance is 100x worse. These heavily-skewed performance characteristics > rendered many ML implementations domain specific. > > I believe OCaml was the first ML to put an unusual amount of effort into > optimizing other aspects, most notably high performance floating-point > arithmetic and float arrays (where OCaml still thrashes SML/NJ and MLton). > Moreover, I think OCaml became the world's favourite ML precisely because > of > this diversity. > > I am just looking at the simplest possible GC implementations, like shadow > stack, and trying to envisage an ML implementation that puts a lot more > effort into numerics and string processing and a lot less effort into > symbolics. I am guessing the performance of allocation will be degraded > 10-100x but many allocations can be removed. This leaves me wondering how > much slowdown is acceptable without deterring a lot of users? > > Anyway, I'll try to implement a simple GC and get some concrete performance > results first... > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > > _______________________________________________ > 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 > ------=_Part_69379_31197055.1230046372462 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > 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? Why can't a compiler be good at numeric and symbolic computation?


On Tue, Dec 23, 2008 at 4:59 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
On Tuesday 23 December 2008 06:07:37 Jon Harrop wrote:
> Yes. I'll do a bit more work on it and then tidy it up and document it
> before uploading it, unless there is any great interest from people now.

Incidentally, I would like to know what performance issues (good and bad)
people have with the current OCaml implementation?

AFAICT, OCaml evolved from a family of languages that were only optimized for
symbolic processing. Some of OCaml's relatives, like PolyML, were able to
provide even faster symbolic processing than naive C but their numerical
performance is 100x worse. These heavily-skewed performance characteristics
rendered many ML implementations domain specific.

I believe OCaml was the first ML to put an unusual amount of effort into
optimizing other aspects, most notably high performance floating-point
arithmetic and float arrays (where OCaml still thrashes SML/NJ and MLton).
Moreover, I think OCaml became the world's favourite ML precisely because of
this diversity.

I am just looking at the simplest possible GC implementations, like shadow
stack, and trying to envisage an ML implementation that puts a lot more
effort into numerics and string processing and a lot less effort into
symbolics. I am guessing the performance of allocation will be degraded
10-100x but many allocations can be removed. This leaves me wondering how
much slowdown is acceptable without deterring a lot of users?

Anyway, I'll try to implement a simple GC and get some concrete performance
results first...

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

_______________________________________________
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

------=_Part_69379_31197055.1230046372462--