ml at isaac.cedarswampstudios.org
Wed Feb 17 02:37:01 EST 2010
On 02/16/10 20:13, Roman Leshchinskiy wrote:
> On 15/02/2010, at 04:58, Don Stewart wrote:
>> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops?
> FWIW, I don't think we even use -fvia-C when benchmarking. In general, -fvia-C is a dead end wrt numeric performance because gcc just doesn't optimise well enough. So even if we generated code that gcc could optimise properly (which we don't atm), we still would be way behind highly optimising compilers like Intel's or Sun's. IMO, the LLVM backend is the way to go here.
LLVM and GCC are open-source projects that are improving over time... is
there any particular reason we expect GCC to have poor numeric
[now I rehash why to remove -fvia-C anyway. Feel free to ignore me.]
...However, we think the native-code backends (and perhaps LLVM) will be
good enough within the next few years to catch up with registerized
via-C; and as soon as they do, it'll be an advantage to remove -fvia-C
so that we're not restricted by C's calling conventions and other such
restrictions. And it's much easier to predict GCC's path for just the
next two years (for example). Actually, even if GCC somehow becomes the
premier optimizer that we'll never be able to replicate with our own
feeble efforts, it still may not be worth keeping/using/maintaining the
current perl hacks for that purpose (combining the effort needed to
maintain them over the time until then, and the effort needed to adapt
these hacks to C with loops that let GCC optimize better... er, it
probably won't be *that much* better except in things simple enough that
it's easier to add optimizations inside GHC than to maintain this
> Before the "Pile on Scooter" fest starts, bear in mind that LLVM effectively restricts you to its current backends. As the guy who started CellSPU in LLVM and who needs a good couple of research months off to finish it, think this through. Carefully.
Currently we have
- "unregisterized", using GCC. This is the most portable, fairly
reliable, and will stay.
- "registerized" (fvia-C), using GCC. This tends to break (e.g.
registerized PowerPC is broken)
- -fasm (native code generator). This can break from refactoring in GHC
but not from new versions of GCC, so it is less annoying than the
And we'll hopefully have
- LLVM backend, with (currently) fewer supported architectures than GCC
but more than GHC's native-codegens.
If you finish your CellSPU work, great! GHC 6.16 or so might be able to
perform well on CellSPU! If not, then the present situation of using the
"unregisterized" (slow) C backend will still be available; we don't lose
much by removing the few current "registerized" backends. (Actually it's
likely to require some build-system fixes in porting to any new
platform, even with the unregisterized backend.) (Also, if it turns out
to be easier to make a GHC native-code generator backend than an LLVM
backend, then maybe that will be yet another theoretical possibility!)
More information about the Glasgow-haskell-users