Limits of possible performance improvements of Haskell/GHC code?

• vector-sorting-benchmarks

  1 1 10.0 C

  I want to beat std::sort with Haskell.

I recently tried to implement quicksort on vectors in Haskell aiming to make it fast enough to be comparable to C++. If you're curious you can check out https://github.com/sergv/vector-sorting-benchmarks. After some time and research on what C++ actually does I reimplemented it in Haskell and the result managed to stay within reasonable % of C++. E.g. sorting 1000 arrays of 20000 8-byte integers on my machine takes 523ms in C++ (with ffi overhead) and 545ms in fastest Haskell algorithm with closest others taking around 650ms.

• countwords

  2 4 10.0 Rust

  Playing with counting word frequencies (and performance) in various languages. (by unhammer)

In addition to what's mentioned, the "default" libraries people use are often not the best-performing ones. E.g. Data.Vector.Hashtables is often much faster than Data.HashMap.Strict (which again is typically faster than Data.Map). And we find performance papercuts in common libraries that may simply be due to not enough people optimising for speed.

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• text

  13 395 8.4 C++

  Haskell library for space- and time-efficient operations over Unicode text. (by haskell)

  

In addition to what's mentioned, the "default" libraries people use are often not the best-performing ones. E.g. Data.Vector.Hashtables is often much faster than Data.HashMap.Strict (which again is typically faster than Data.Map). And we find performance papercuts in common libraries that may simply be due to not enough people optimising for speed.

Suggest a related project