使用 numpy/scipy 进行空载吞咽
有没有人将 unladen-swallow 与 numpy/scipy 用于数字/科学应用程序？根据您的体验，速度明显更快吗？任何意见都会很棒。
has anyone used unladen-swallow with numpy/scipy for numeric/scientific applications? Is it significantly faster in your experience? Any opinions would be great.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
目前还没有人对 Unladen Swallow 拥有丰富的经验（除了开发人员），因此很难找到很多人可以讨论它。此外，随着将 Unladen Swallow（使用 LLVM 构建）与 CPython 运行时合并的讨论，事情将会变得在一切变得更加稳定之前，这是一个移动的目标。
Unladen Swallow 有可用的基准，但不包括 numpy 和 scipy。 正如开发人员自己解释的那样：“...扩展模块的性能像 numpy 一样无趣，因为 numpy 的核心例程是用 C 实现的”。
简而言之，如果您为
numpy和scipy编写了良好的代码，您的代码在 Unladen Swallow 下不会运行“明显更快”，因为它已经在虚拟机下运行机器级别。如果您为numpy和scipy编写了错误的代码，则需要修复代码，然后返回到第一句话。Nobody has extensive experience with Unladen Swallow yet (except the developers), so it's going to be difficult to find many people who can discuss it. Also, with the talk of merging Unladen Swallow (which is built using LLVM) with the CPython runtime, things are going to be something of a moving target until everything's more stable.
There are benchmarks available for Unladen Swallow, but numpy and scipy aren't included. As the developers themselves explain: "... the performance of extension modules like numpy is uninteresting since numpy's core routines are implemented in C".
In short, if you're writing good code for
numpyandscipy, your code won't run "significantly faster" under Unladen Swallow, since it's already running below the virtual machine level. If you're writing bad code fornumpyandscipy, you need to fix your code, then refer back to the first sentence.应该会更快。我自己还没有测试过，但我刚从 pycon 回来，他们进行了一次关于 unladen-swallow 的讨论，其中提到了 numpy 和其他包的性能提升。您可以在此处观看演讲。
It should be faster. I have not tested it myself, but i just got back from pycon and they had a talk about unladen-swallow in which they mentioned the performance increase with numpy and other packages. You can watch the talk here.
关于这个问题，而不是答案：
没有关于这 3 个如何分裂的真实数据 - 20 70 10, 40 40 20 ？并且对于> 1 个基准，
没有办法知道哪条路是向上的。
On the question, not an answer:
Without real data on how these 3 split -- 20 70 10, 40 40 20 ? and that for > 1 benchmark,
there's no way of telling which way is up.