<div dir="ltr"><div dir="ltr">Am Mo., 8. Apr. 2019 um 16:14 Uhr schrieb William Yager <<a href="mailto:will.yager@gmail.com">will.yager@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">[...] 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. [...]<br></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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..."</div><div><br></div><div>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> ;-)</div></div></div>