Skip to main content

IOG GHC Update #26

· 4 min read

Triweekly update from the GHC DevX team at IOG.

Previous updates can be found here.

High level summary​

The team contributed to fixing issues blocking the GHC 9.10 alpha 1 release.

We continued investigating cardano-node performance and found that the lack of specialization of polymorphic functions is causing a large amount of allocations. Manually removing the polymorphism caused the amount of allocations to drop by 50% in one instance.

We summarized the results of the IOG internal Haskel Tooling survey we conducted in January 2024. A summary of the results can be found in the last section of this blog post. According to the results, we should continue to work on improving compiler performance, documentation, and profiling tools. We should also begin to work on improving HLS stability and performance.

Details​

  • Jeff/Sylvain: investigated and fixed an issue with the "Non-punning list and tuple syntax" patch (GHC!12130, GHC!8820), delaying GHC 9.10 alpha release.

  • Sylvain: summarized results of IOG internal Haskell Tooling survey conducted in January 2024 (summary below).

  • Sylvain: reviewed GHC!12179. Opened GHC#24566 as a follow-up issue and fixed it in GHC!12268

  • Sylvain/Josh: made some JS numeric primitives faster by aoviding the use of BigInt GHC!12125

  • Luite: Worked on experimental GHC tooling to investigate a performance regression in cardano-node. Some new things tried were: Profiling by sampling STG call stacks (using libdw to resolve symbol names), call-site ticky counters for dictionary passing, building a dynamic call graph by recording all calls in the whole program. So far, this has led the the identification of a specific issue where GHC failed to specialize, resulting in an excessive amount of allocation.

  • Jeff: started characterizing preformance of Haskell codes with and without the tables-next-to-code optimization

IOG internal Haskell Tooling survey 2024​

The Haskell Tooling Survey 2024 revealed insights into users' experiences, challenges, and desires for improvement across various tools in the Haskell ecosystem:

GHC:

  • Users expressed concerns about slow compilation times, especially on low-power devices, and desires for a lightweight toolchain with a small runtime and quick installation process. Some also highlighted worries about the declining popularity of Haskell and its potential impact on the language's future.

Cabal:

  • Users reported frustrations with Cabal, including issues with rebuilding dependencies unnecessarily, confusing solver errors, and its aging build system. Desired improvements included simplifying the Cabal build process, better documentation, and integration with other languages.

Haskell Language Server (HLS):

  • HLS users faced daily annoyances such as slow performance, crashes, and flakiness. Desired improvements included better integration with GHC, addressing polyrepo structure issues, and fixing specific template Haskell-related problems.

haskell.nix:

  • Users desired improvements to haskell.nix, including cleaning up documentation, providing more canonical examples, and addressing issues like unnecessary recompilation of libraries.

IDEs and Editors:

  • Users expressed a need for better IDE support, with desires for faster and more robust IDEs comparable to modern IDEs like IntelliJ. They also highlighted challenges in setting up tools like HLS with Nix and VSCodium.

Documentation and Learning Material:

  • Suggestions included the creation of a completed Haskell optimization handbook, improvement of Cabal documentation, and more comprehensive resources for onboarding new developers.

GHC's WebAssembly/JavaScript Backends:

  • Interest in using GHC's WebAssembly/JavaScript backends varied, with some expressing likelihood of use for GUIs and mobile devices, while others cited limitations in library compatibility as barriers to adoption.

Debugging and Analyzing Tools:

  • Responses varied regarding satisfaction with debugging and analyzing tools, with some users desiring a more integrated experience and others finding the existing tools adequate.

Future Concerns:

  • Users expressed worries about the declining popularity of Haskell, undisciplined use of language extensions, potential company bankruptcies affecting support for GHC, competition from other languages, and lack of full-time maintenance resources.

Desired Changes:

  • Users desired improvements such as a lightweight toolchain, better support for ambiguous record fields, increased full-time tooling contributors, improved cross-platform build process, and a focus on regaining Haskell's status as a language of innovation.