[Haskell-cafe] GHC extensions

[Sven Panne]

Am Mo., 8. Apr. 2019 um 16:14 Uhr schrieb William Yager <
will.yager at gmail.com>:

> [...] As a heuristic, I would hand-wavily claim that GHC typically tries
> its hardest to avoid type-level abstractions introducing value-level
> performance overhead, but it also doesn't try especially hard to use
> type-level abstractions to inform the optimizer.  I think it's unlikely
> that turning on fancy type-system features will make your code go *faster*,
> but as long as you're careful it probably also won't go slower. [...]
>

This is basically my view on all the extensions, too. In my POV, the
primary goal of all those fancy typing extensions is to make the set of
programs which can statically be proven "to not go wrong" larger and has
nothing to do with performance per se. There are of course extensions which
can be used to improve performance, like the relatively recent stuff which
allows you to coerce different things in a safe way, but AFAIK you have to
give GHC a helping hand here by stating your intentions.

All this typing magic is somehow the opposite of what a JIT does. An
optimizing JIT basically says: "Hey, from what I've seen so far by
executing your program, I can do the FOOBAR optimization. Of course this is
wrong in the general case, but let's nevertheless use FOOBAR until I'm
proven wrong by further executing your program. Then I can undo FOOBAR,
anyway..."

In other words: A traditional optimizing compiler statically proves things,
an optimizing JIT dynamically assumes things. What is better for
performance very much depends on what you're doing.,,, </HandWaving> ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190408/78356cef/attachment.html>