On 12/7/05, Greg Buchholz <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > It might be possible to get extremely fast code out of ghc, but as an > > overall > > impression, it's not easy, whilst Clean sort of gives it for granted (well, > > struggeling with wrongly assigned uniqueness attributes aside). > > <snip> > > > programs generated by ghc generally need multiples of time and space of the > > Clean version, even though the latter is, in many cases, a nearly literal > > translation from Haskell. > > Maybe you'd be interested in Hacle? > > http://www-users.cs.york.ac.uk/~mfn/hacle/ > > " The aim was to develop a translator which is capable of reading in any > given Haskell'98 program and writing out a semantically equivalent Clean > one. Why? To investigate the suitability of the Clean compiler for > compiling Haskell programs, i.e. Can the Clean compiler, in combination > with this tool, produce faster executables than existing Haskell > compilers? "
That looks interesting. I wonder what the results mean =) It could be that Clean and Haskell are roughly equivalent in speed (modulo som variance), or it could mean that GHC is great at optimizing Haskell code, but in certain cases uniqueness typing (among other things?) gives so much benifits that it outweights GHC's optimization. It definatly means that there are cases where GHC could improve significantly. Nevertheless, Haskell speed is definatly a big issue for many. It is a general purpose language, after all, and that makes speed important. For "single-purpose" languages like, say, php it's not as important (because you're not going to write, say, a game engine in php for reasons other than speed). Haskell is certainly better now than it used to be, but there's plenty of room for improvement. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe