sutton036

Cofounder of Flying Frog Consultancy Ltd. , Dr Jon Harrop, did his PhD at the University of Cambridge on the "Structural properties of Amorphous Materials" in the department of chemistry. A large part of this work was on the application of time-frequency analysis to the study of the diffraction data of amorphous materials. The complete PhD thesis is now freely available for download as a PDF here . In the process, Dr Harrop developed a new approach to time-frequency analysis that is based upon the continuous wavelet transform (CWT). This method of analysis is applicable to a wide variety of signals that arise in many different areas of study including biology , physics , finance , engineering , and bioinformatics . Chapter 2 introduces the method of time-frequency analysis and discusses various different approaches that have been invented over the years. In particular, the beneficial charactistics of the continuous wavelet transform are described in detail, along with the mat...

Miguel de Icaza of the Mono project made two surprise announcements in a recent blog post : "We are working to improve our support for F# and together with various groups at Microsoft we are working to improve Mono's compatibility with the CLR to run IronPython, IronRuby and F# flawlessly in Mono. Supporting F# will require some upgrades to the way that Mono works to effectively support tail call optimizations." "we continue to work on integrating LLVM [better use LLVM to produce better code, use it in more places where the old JIT was still required and expand its use to be used for AOT code]" We have been pushing for these developments (F# support and an LLVM backend) for over a year now and it is very exciting to hear that the Mono team are taking this seriously. F# is the future of .NET and building upon LLVM offers huge potential not only for improving upon the performance of Mono's code generator but also in improving LLVM itself, which is now the ...

For a bit of fun, we recently ran programs to determine the current sizes of our company's OCaml and F# code bases. This includes the code we use in-house for everything from web analytics to accountancy as well as the code behind our commercial products . We found 345kLOC of OCaml code and 171kLOC of F# code. In comparison, Jane St. Capital now have around a million lines of production OCaml code and Citrix have 130kLOC of production OCaml code .

The latest OCaml Journal article High-performance parallel programming with HLVM (23rd January 2010) described a simple but effective parallelization of the HLVM implementation of the ray tracer. Comparing with similarly naive parallelizations of the fastest serial implementations in C++ and Haskell, we obtained the following results: These results exhibit several interesting characteristics: Even the naive parallelization in C++ is significantly faster than HLVM and Haskell. C++ and HLVM scale well, with performance improving as more cores are used. Despite having serial performance competitive with HLVM, the naively-parallelized Haskell scales poorly. In particular, Haskell failed to obtain a competitive speedup with up to 5 cores and its performance even degraded significantly beyond 5 cores, running 4.4× slower than C++ on 7 cores. The efficiency of the parallelization can be quantified as the speed of the parallel version on multiple cores relative to its speed on a single core:...

Since the publication of our recent article about the upcoming ARM architecture in the context of the exploding netbook market, Marvell have announced their production of the world's first quadcore ARM CPU . ARM also announced 2GHz capable Cortex-A9 cores in September 2009. Hopefully we'll get the chance to port our new multicore-capable HLVM project to the ARM architecture before long. That should be an easy task thanks to LLVM's existing support for ARM and LLVM is already used on the Apple iPhone, which is ARM based.

Several people including Simon Marlow of Microsoft have objected to our rejection of Saynte's new Haskell code, claiming that the alterations were minor and that they optimize serial performance. This is simply not true. Firstly, over half of the lines of code in the entire program have been altered. Secondly, the new version is slower than Lennart's original version 5 on 1 core. So there is no logical reason to choose the revised Haskell for the basis of a naive parallelization unless you want to cherry pick results by leveraging knowledge of how they will scale after parallelization. Suffice to say, doing so would be bad science. This is illustrated in the following graph of performance results for Lennart's original version 5 vs Saynte's new revised Haskell with 11 levels of spheres at 1,024×1,024: The original code is 5% faster on 1 core but scales poorly and is 2.7× slower on 7 cores. The substantially-revised "serial" Haskell code was obviously specif...

A member of the Haskell community recently published a blog article revisiting our ray tracer language comparison, claiming to address the question of how naïve parallelizations in these two languages compare. The objective was to make only minimal changes to the programs in order to parallelize them and then compare performance. Our attempts to verify those results turned up a lot of interesting information. Firstly, the Haskell program that was supposedly naïvely parallelized was not the original but, in fact, a complete rewrite. This raises the question of whether or not the rewrite was specifically designed to be amenable to parallelization and, therefore, is not representative of naïve parallelization at all. The C++ used was the original with minimal changes to parallelize a single loop. Secondly, although the serial benchmark results covered a spectrum of inputs, the parallel results covered only a single case and retrospectively identified the optimal results without alluding ...