Browse thread
compiler bug?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Brian Hurt <bhurt@s...> |
| Subject: | Re: [Caml-list] compiler bug? |
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