sutton036

Simon Marlow of Microsoft Research recently published a blog post entitled First results from GHC's new garbage collector . As his beautiful graphs show so clearly, this is a first step towards concurrent garbage collection. The blog post describes this advancement entirely from the perspective of throughput because the ability to collect per-thread nursery generations independently removes some of the blocking that was wasting mutator time in the previous version. However, we believe that concurrent programming may become a killer application domain for Haskell and, in that context, latency can be critical. If GHC's garbage collector is made more concurrent, by allowing the old generation to be collected independently as well, then pause times could be greatly reduced and Haskell would have a considerable advantage over competing technologies like .NET. We have found that even the best-behaved .NET programs that allocate still suffer GC pauses of around 20ms, over an order of ...

We recently completed a translation of our famous ray tracer language comparison to HLVM . The translation is equivalent to the most highly optimized implementations written in other languages and this allows us to compare HLVM with a variety of competing languages for the first time. The results are astonishing. Running the benchmark with the default settings (level=9, n=5 to render 87,381 spheres at 512×512) on 32-bit x86 gives the following times for different languages: These results show that HLVM already provides competitive performance for a non-trivial benchmark. HLVM took 6.7s whereas C++ (compiled with g++ 4.3.3) took only 4.3s and Haskell (compiled with GHC 6.12) took 13.9s. However, cranking up the level parameter to 12 in order to increase the complexity of the scene, rendering a whopping 5,592,405 spheres, we find that HLVM blows away the other garbage collected languages and is even able to keep up with C++: This remarkable result is a consequence of HLVM's space-ef...

Peter Verswyvelen of Nazooka , one of the only industrial users of Haskell, uncovered another serious bug in GHC, the defacto-standard Haskell compiler. The bug afflicts floating point arithmetic in external libraries such as Qt, GTK, OpenGL, BLAS, LAPACK and FFTW on x86. Peter said "It's insane this bug did not cause any more problems. Every call into every C function that uses floating point could have been affected". Given that this bug had gone unnoticed for so long, the only logical conclusion is that the GHC FFI is immature because it has very few users. This concurs with our previous findings that no mature software has ever been written in Haskell. Moreover, this bug joins the list of serious FFI-related bugs in GHC along with the subtle FFI bug in GHC that helped to destroy Darcs and a memory alignment bug in GHC's FFI that caused segmentation faults. Suffice to say, the moral of this story is that even the most advanced high-level programming language impl...