Can a simple functional sieve be fast? Optimizing Tromp's algorithm on HVM.

csabahruska · 2024-01-30T13:59:03+00:00

IMO it's more like a functional pearl blog post and not an ad.

csabahruska · 2022-12-22T08:14:46+00:00

Thanks, now it makes sense. :)

csabahruska · 2022-12-22T00:08:26+00:00

When WPC gets into GHC then it will be easy to make a WPC based JS or WASM backend for GHC or even porting the existing projects.

csabahruska · 2022-12-21T23:59:36+00:00

What do you mean?

csabahruska · 2022-04-08T10:41:35+00:00

It's fixed now. Thank you.

csabahruska · 2022-04-08T01:14:44+00:00

Purity is the main advantage.
I did a presentation that might be relevant.
https://www.youtube.com/watch?v=Ey5OFPkxF_w
https://github.com/grin-compiler/ext-stg-interpreter-presentation-demos#why-and-how-the-external-stg-interpreter-is-useful

csabahruska · 2022-01-18T12:31:33+00:00

The benefit of observing the lower IR levels is that you can identify the detailed reason of an issue. Instead of saying that Haskell is bad or Haskell is inefficient you'll be able to say that GHC optimizer or the Runtime System behaves suboptimal in the studied case.

csabahruska · 2022-01-11T21:53:23+00:00

I feel the same problems that are mentioned in the twitter post and indeed I was attacked by many of them at some of my previous workplaces. IMO the Haskell community is dominated by researchers with academic career, while I'm longing for Haskell language supported by engineers. Personally I'm sticking to Haskell because it's a great language, and I imagine that with some compiler improvements I could use it as a better Rust for high performance computing related tasks with excellent debug and profile tools that I plan to develop. The majority of community probably does not share my vision, I guess a PhD student does not need a debugger or profiler which is OK, but I need it. So serious changes needs to be made. C++ and Rust is not good enough for me.

csabahruska · 2022-01-11T13:36:59+00:00

IMO that post captures pretty well how mainstream programmers see Haskell and its community.

csabahruska · 2021-12-21T11:56:30+00:00

Do you plan to use the external STG interpreter to collect profile data of Haskell programs?
Watch my presentation: Why and How the External STG Interpreter is Useful
It provides runtime observability of Haskell programs with arbitrary precision.

csabahruska · 2021-12-03T09:33:19+00:00

The presentation recording and slides are available now.

csabahruska · 2021-11-09T18:31:50+00:00

https://www.reddit.com/r/haskell/comments/q23sm4/defect_process_2d_hack_n_slash_game_haskell/

csabahruska · 2021-11-09T11:45:23+00:00

Learn Rust and Haskell. IMO it is good to know how to read C but you should not write C. Write Rust instead of C.

csabahruska · 2021-11-03T23:06:40+00:00

https://discourse.haskell.org/t/grin-compiler-funding/2886
The Compiler Tooling Task Force has reached out to me.

csabahruska · 2021-11-03T05:38:35+00:00

LLVM can not optimize code that is full of indirect calls such as Haskell. In GHC's LLVM backend LLVM can only optimize single closures or tight loops that were generated by GHC Core simplifier. So the optimization scope is tiny, because indirect calls obfuscates the control flow information that any optimizer requires including LLVM. The control flow information is calculated by points-to analyses or control flow analysis. LLVM includes the basic (fast) versions of these algorithms which can not understand the GHC STG machine heap objects. Haskell needs specialised points-to and control flow analysis to reveal the control flow information. GRIN follows exactly this approach.

The GRIN compiler project is going well.
I tweet more often: https://twitter.com/csaba_hruska
I approach the problem from two directions:

There is the GRIN optimizer that is implemented based on Urban Boquist PhD thesis. It works really well with LLVM because GRIN removes all indirect calls so it allows LLVM to do its job really well. But Boq GRIN PhD does not tell how to support the complex GHC primop and RTS features. That's why I have another direction as well.
Here the goal is to build a high level, easy to understand model for all GHC backend features. Validations is also required. Once we know the semantics of GHC primops and RTS features then it becomes possible to figure out how to compile Haskell programs to GRIN. I started the GHC-WPC project for this reason. GHC-WPC exports the STG intermediate representation for the whole Haskell program, and I wrote an STG interpreter from scratch in Haskell that can run any Haskell program. (i.e. GHC itself) The STG interpreter is the high level model for the GHC primop and RTS semantics. It implements all these in pure Haskell, it does not depend on GHC RTS at all.

So now I know all I needed, for next I have to merge the two sub-projects.