Speeding up compile times would be excellent! Do you have benchmarks? Estimates?

ZuriHac is coming up, and I want to devote my participation time to improving ghc's usability, one way or another. Improving compile times would be the best usability boon I can think of. If there is promise in this project, I'd like to learn about any way I could help out.


On Thu, 9 May 2019, 15.54 james faure, <james.faure@epitech.eu> wrote:
Hello,
I want to introduce the STG backend I am currently working on:
I'd love to see how much interest there is for this, to receive any comments, and find out if I've missed anything !

The goal is to massively speed up compilation times and generate faster and clearer code, and in that respect I am already quite successful. Llvm is very well suited for encoding a (lazy) functional language, however the evaluation mechanism is very different to ghc's stg, there is notably no continuation passing nor result registers. In LFVM, all non constant let bindings are given an llvm function. I believe this approach is more natural, the llvm more accurately reflects the source code and we get proper stack traces in a debugger.

Status:
The project is barely a month old, and I'm working to support everything ghc's code generation supports.
The STG is heavily based on the one found in ghc and, at this time and as far as I can tell, supports everything except multithreading, a gc and lazy evaluation. The current idea I think is very promising is to use an inferred pi calculus to elegantly implement all 3 missing parts at once.

Pi calculus [1] (process calculus) In the STG
  • Multithreading occurs for arguments of functions with >1 arity
  • Perfect garbage collection is quite probably possible [2], where allocation creates a new pi name, and its uses are modeled by pi calculus communication
  • Perfect Lazy evaluation (in the sense that the wrapper and associated wrapped type overhead is coerced away after the first evaluation) is possible in the pi calculus and closely linked the gc model. I intend to make strict evaluation the default, If you want lazy (for MonadFix or infinite lists or whatever), you must request it.

James Faure (Discord: J4#0303)

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.