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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 0E7F1BB84 for ; Fri, 19 May 2006 04:16:57 +0200 (CEST) Received: from luna.vie.lunde.net (at.lunde.net [62.116.13.60]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4J2Gu4B026980 for ; Fri, 19 May 2006 04:16:56 +0200 Received: from h-68-166-100-33.nycmny83.covad.net ([68.166.100.33] helo=localhost.localdomain) by luna.vie.lunde.net with asmtp (Exim 3.36 #1 (Debian)) id 1FguXm-0008H1-00; Fri, 19 May 2006 04:16:46 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 6E794300F8; Thu, 18 May 2006 22:17:28 -0400 (EDT) Date: Thu, 18 May 2006 22:17:28 -0400 (EDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: skaller Cc: Jacques Carette , caml-list@yquem.inria.fr Subject: Re: [Caml-list] compiler bug? In-Reply-To: <1148003249.25630.29.camel@rosella.wigram> Message-ID: References: <20060517231426.30289.qmail@web32203.mail.mud.yahoo.com> <446CABCA.8000906@inria.fr> <446CB021.6000009@mcmaster.ca> <1147976357.25630.27.camel@rosella.wigram> <446CC2C1.5040801@mcmaster.ca> <1148003249.25630.29.camel@rosella.wigram> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 446D2A98.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; compiler:01 bug:01 haskell:01 untyped:01 high-level:01 compiler:01 2006:98 wrote:01 wrote:01 caml-list:01 syntactic:01 ghc:01 jacques:01 modules:01 tend:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Fri, 19 May 2006, skaller wrote: > On Thu, 2006-05-18 at 14:53 -0400, Jacques Carette wrote: >> skaller wrote: >> >>> What about high level optimisations? >>> >>> Felix supports this: >>> >>> reduce revrev[t] (x:list[t]): rev (rev x) => x; > >> Haskell (GHC to be precise) allows that too. But is syntactic >> term-rewriting, in other words it is *untyped*. > > It's well typed. x:list[t] means x is of type list[t]. I'm just wondering how often such optimizations are worthwhile. From what I've read, basic register allocation and peephole optimizations gain you 2x the performance- after that, it's a fight for percentage points. Especially considering that humans tend to be a lot better at recognizing opportunities for high-level optimizations than computers are. For example, a human would be much more likely to notice a double list reversal when the two reversals are in seperate modules, or otherwise obscured from the compiler. Even more so, the programmer may decide that maybe a list isn't the right datastructure for this data- a decision I wouldn't trust to a compiler. Brian