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 performance forever? [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 backend anyway). scooter.phd wrote:
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 -fvia-C path. 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!) -Isaac