On 17/02/10 07:37, Isaac Dupree wrote:
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?
The problem is not the quality of the code generator in gcc vs. LLVM; indeed gcc is generally regarded as generating better code than LLVM right now, although LLVM is improving. The reason that using gcc is worse than LLVM for us in that when GHC uses gcc as a backend it generates C, whereas the LLVM backend generates code directly from GHC's internal C-- representation. Compiling via C is a tricky business that ultimately leads to not being able to generate as good code as you want(*). It would be entirely possible to hook into gcc's backend directly from GHC as an alternative to the LLVM backend, though LLVM is really intended to be used this way and has a more polished API. Even so, LLVM doesn't let us generate exactly the code we'd like: we can't use GHC's tables-next-to-code optimisation. Measurements done by David Terei who built the LLVM backend apparently show that this doesn't matter much (~3% slower IIRC), though I'm still surprised that all those extra indirections don't have more of an effect, I think we need to investigate this more closely. It's important because if the LLVM backend is to be a compile-time option, we have to either drop tables-next-to-code, or wait until LLVM supports generating code in that style. (*) Though the main reason for this is the need to keep accurate GC information; if you're prepared to forego that (as in JHC) then you can generate much more optimisable C code.
[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;
I should point out that for most Haskell programs, the NCG is already as fast (in some cases faster) than via C. The benchmarks showing a difference are all of the small tight loop kind - which are important to some people, I don't dispute that, but I expect that most people wouldn't notice the difference. Cheers, Simon