[Haskell-cafe] Re: Haskell version of ray tracer code is muchslower than the original ML

[Claus Reinke]

on second thought, user-defined profiles are a two-edged sword,
negating the documentation advantages of in-source flags. better to
handle that in the editor/ide. but predefined flag profiles would still
seem to make sense?

there is something wrong about this wealth of options. it is great 
that one has all that control over details, but it also makes it more 
difficult to get things right (eg, i was surprised that -O doesn't 
unbox strict fields by default). even a formula one driver doesn't 
control every lever himself, that's up to the team.

for optimisations, i used to have a simple picture in mind (from
my c days, i guess?), when ghci is no longer fast enough, that is:

no -O: standard executables are fast enough, thank you

-O: standard executables aren't fast enough, do something
    about it, but don't bother me with the details

-O2: i need your best _safe_ optimisation efforts, and i'm 
    prepared to pay for that with longer compilation times

-O3: i need your absolute best optimisation efforts, and i'm 
    prepared to verify myself that optimisations that cannot 
    automatically be checked for safety have no serious negative 
    effect on the results (it would be nice if you told me which
    potentially unsafe optimisations you used in compilation)

on top of that, as an alternative to -O3, specific tradeoffs would
be useful, where i specify whether i want to optimize for space
or for time, or which kinds of optimization opportunities the
compiler should pay attention to, such as strictness, unboxing,
floating point ops, etc.. but even here i wouldn't want to give
platform-specific options, i'd want the compiler to choose the
most appropriate options, given my specified tradeoffs and
emphasis, taking into account platform and self-knowledge.

so, i'd say -Ofp, and the compiler might pick:

>>   -fvia-C -fexcess-precision -optc-mfpmath=sse2

if i'm on a platform and compiler version where that is an 
appropriate selection of flags to get the best floating point
performance. and it might pick a different selection of flags
on a different platform, or with a different compiler version.

> perhaps this should be generalised to ghc flag profiles, to cover
> things like '-fno-monomorphism-restriction -fno-mono-pat-binds'
> or '-fglasgow-exts -fallow-undecidable-instances; and the like?

that is a slightly different story, and it might be useful (a) to 
provide flag groups (-fno-mono*) and (b) to specify implication
(just about every language extension flag implies -fglasgow-exts,
so there's no need to specify that again, and there might be
other opportunities for reducing groups of options with a
single maximum in the implication order; one might even 
introduce pseudo-flags for grouping, such as -fhaskell2;-).

claus