Thanks for pushing data haskell! I have a minor off-topic comment about this blog post and probably the rest of the blog/website: it is really hard to read the text for me. The font is very skinny; the contrast between the text color and the background color is too low; finally, the background color is too bright for my eyes. I’d appreciate it if this issue could be fixed.
On to it. What do you think of the light and dark versions of this page?
Much better, thanks! The light version has no issue to my eye. The dark version has almost everything right except for the contrast: I’d make the font lighter or the background darker (or both). But it’s much easier to read for me already!
We’re still cleaning up from the last dataHaskell crew. It was the gitter era, and I think we’ve all memory-holed just how skinny fonts got: https://gitter.im/
How do you reach the conclusion that MicroHs is slower than GHCi? Interactive mhs runs at the same speed as compiled mhs. I tried the follwing benchmark:
data T = Leaf Int | Node T T
mkT :: Int -> T; mkT 1 = Leaf 1; mkT n = Node (mkT (n-1)) (mkT (n-1))
sumT (Leaf n) = n; sumT (Node t1 t2) = sumT t1 + sumT t2
And mhs is about twice as fast as GHCi. I’d be interested to see what benchmark you used and see if I can speed it up.
I don’t have my laptop with me this weekend so I can’t share the specific example. But on my computer calling some compiled code that does unboxed array computation was slower than calling that same code in ghc. I think in this case ghci was more of a front end than the compute engine. I’m yet to test standalone computations as you’ve done.
Also in the iHaskell vs Xeus Haskell context - iHaskell is a ghc interpreter that wraps some compiled code as in in the ghci case. But xeus seems to ship all of microhs as one big interpreter in WASM which makes the compute difference more noticeable.
So I’m not sure that’s necessarily a microhs thing as it is a delivery method thing.
Yeah, if most of what you do is calling compiled code then ghc will be a lot faster.