Some great results on fused code with the LLVM backend
I tried out some of the vector and uvector fusion benchmarks with the new LLVM backend http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs... and got some great results for the tight loops generated through fusion. Up to 2x faster than gcc -O3 in some cases. The LLVM backend looks very promising -- considering we've not even begun to explore the optimization pipeline at the level. -- Don
On Mon, Feb 22, 2010 at 2:57 AM, Don Stewart
I tried out some of the vector and uvector fusion benchmarks with the new LLVM backend and got some great results for the tight loops generated through fusion.
This is excellent news!
The LLVM backend looks very promising -- considering we've not even begun to explore the optimization pipeline at the level.
There is a complete cake at: http://llvm.org/docs/Passes.html (yes, I dabbled in LLVM for some time) Some of the analysis passes gives us a nice hook into the toolchain when you want to see what is going on at the lowest level. Some of the transformations will, perhaps, yield some speedups. -- J.
On Feb 22, 2:57 am, Don Stewart
TheLLVMbackend looks very promising -- considering we've not even begun to explore the optimization pipeline at the level.
The mere numbers on this tiny snipets look definitely promising. I also read through http://hackage.haskell.org/trac/ghc/wiki/LlvmBackend but I wonder what componentes of the LLVM infrastructure will eventually make it into GHC. Will this eg mean * interoperability between LLVM assemblies for free * plugable garbage collectors * GHC/LLVM bytecode with JIT-option?
-- Don
Johann
_______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, Feb 24, 2010 at 10:11 AM, Johann Höchtl
Will this eg mean
* interoperability between LLVM assemblies for free
* plugable garbage collectors
Keep in mind the LLVM GHC backend still uses the separate Haskell stack and uses a custom calling convention, so LLVM's garbage collection support isn't used at all, it is still a rather strange duck as far as the rest of the LLVM ecosystem is concerned.
* GHC/LLVM bytecode with JIT-option?
There is little preventing this one. -Edward Kmett
On Wed, Feb 24, 2010 at 01:28:56PM -0500, Edward Kmett wrote:
* GHC/LLVM bytecode with JIT-option?
There is little preventing this one.
Oh, what a great idea! C code being inlined into Haskell functions! :D If clang were used to compile the C code into LLVM IR, and everything were linked by LLVM, bang!, the link-time optimizer would take care of inlining cheap functions into Haskell code that uses them. Cheers, =) -- Felipe.
Felipe Lessa schrieb:
On Wed, Feb 24, 2010 at 01:28:56PM -0500, Edward Kmett wrote:
* GHC/LLVM bytecode with JIT-option? There is little preventing this one.
Oh, what a great idea! C code being inlined into Haskell functions! :D
How about LLVM inline assembly code? You can already do this using the 'llvm' package.
participants (6)
-
Don Stewart -
Edward Kmett -
Felipe Lessa -
Henning Thielemann -
Jesper Louis Andersen -
Johann Höchtl