Haskell 中可能的优化尚未在 GHC 中实现?

发布于 2024-10-12 05:47:52 字数 1436 浏览 4 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

烟─花易冷 2024-10-19 05:47:53

我希望在 GHC 中看到的一项优化是超级编译。不过,在 GHC 的不久的将来,这似乎不太可能,因为它是整个程序优化,并且 GHC 非常关注一次模块编译。

基本上,超级编译是在编译时执行尽可能多的程序。它自然地包含内联、森林砍伐、专业化和许多其他技术。早期的实验结果很有希望,但这是一个非常昂贵的过程。很难看出这是一个实用的优化,但这个概念非常棒。

One optimization I'd love to see in GHC is supercompilation. That seems unlikely in the near-future of GHC, though, because it's whole-program optimization, and GHC is very focused on module-at-a-time compilation.

Basically, supercompilation is executing as much of a program as possible at compile time. It naturally subsumes inlining, deforestation, specialization, and any number of other techniques. Early experimental results have been promising, but it's a very expensive process. It's hard to see it being a practical optimization, but the concept is ridiculously awesome.

久隐师 2024-10-19 05:47:53

SPJ 在关于模块化超级编译的论文中指出的另一个问题是将超级编译与拆箱相结合。超级编译程序中拆箱的可能性大大降低。与通过 GHC 严格分析器/拆箱器的未优化程序相比,这会导致性能下降。请参阅http://research.microsoft.com/en-us /um/people/simonpj/papers/supercompilation/

Another issue that SPJ states in his paper on modular supercompilation is combining supercompilation with unboxing. Possibilities for unboxing in supercompiled program are significantly reduced. This causes decrease in performance in comparison with unoptimized program passed through GHC strict-analyser/unboxer. See http://research.microsoft.com/en-us/um/people/simonpj/papers/supercompilation/

好倦 2024-10-19 05:47:53

另一种强大但“尚未准备好用于生产使用”的技术是worker-wrapper 转换< /a>.

Another powerful but also "not yet ready for production use" technique is worker-wrapper transformation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文