TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Attempts to make Python fast

135 点作者 Queue29超过 4 年前

18 条评论

the_mitsuhiko超过 4 年前
Python is fundamentally not designed to be faster because it leaks a lot of stuff that’s inherently slow that real world code depends on. That’s mutable interpreter frames, global interpreter locks, shared global state, type slots, the C ABI.<p>The only way to speed it up would be to change the language.
评论 #24849240 未加载
评论 #24849302 未加载
评论 #24848948 未加载
评论 #24849017 未加载
评论 #24849800 未加载
评论 #24849079 未加载
评论 #24849777 未加载
评论 #24849366 未加载
评论 #24849357 未加载
评论 #24849603 未加载
评论 #24848943 未加载
评论 #24848931 未加载
评论 #24849374 未加载
评论 #24849868 未加载
bastawhiz超过 4 年前
Ultimately, at least IMO, no attempt to speed up python will succeed until the issue of Python&#x27;s C API is addressed. This is arguably Pypy&#x27;s only major barrier: if you can&#x27;t run the software on it, you&#x27;re not going to use it. Pyston was arguably the most serious attempt at fast python while maintaining compatibility with the API, but DBX clearly didn&#x27;t see the RoI they were hoping to.<p>It&#x27;s looking like HPy is going to (hopefully) solve this. But finishing HPy and getting it adopted is likely to be a pretty massive undertaking.
评论 #24848735 未加载
评论 #24848779 未加载
评论 #24848739 未加载
intrepidhero超过 4 年前
What I really want for python is a knob to improve startup time. I&#x27;ve imagined there must be a way to &quot;statically link dependencies so that import isn&#x27;t searching the disk but just loading from a fixed location&#x2F;file. There doesn&#x27;t seem to be many resources on the net. I&#x27;ve found this one: <a href="https:&#x2F;&#x2F;pythondev.readthedocs.io&#x2F;startup_time.html" rel="nofollow">https:&#x2F;&#x2F;pythondev.readthedocs.io&#x2F;startup_time.html</a>. I tried using virtualenvs to limit my searchable import paths, and messed around with cython in effort to come up with a static linked binary. But I&#x27;ve yet to come up with anything that really improves the startup time. Clearly I have no idea what I&#x27;m doing.
评论 #24849128 未加载
评论 #24849184 未加载
评论 #24849148 未加载
评论 #24856168 未加载
评论 #24849124 未加载
评论 #24859637 未加载
评论 #24849243 未加载
评论 #24849436 未加载
joncatanio超过 4 年前
Not trying to self-promote, but this might be of interest to you. It&#x27;s not a fully flushed out implementation, but my project analyzed specific language features that affect performance: <a href="https:&#x2F;&#x2F;github.com&#x2F;joncatanio&#x2F;cannoli" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;joncatanio&#x2F;cannoli</a>
评论 #24848932 未加载
评论 #24848807 未加载
sethgecko超过 4 年前
Yuri Selivanov tweeted yesterday that Python 3.10 will be &quot;up to 10% faster&quot; <a href="https:&#x2F;&#x2F;twitter.com&#x2F;1st1&#x2F;status&#x2F;1318558048265404420" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;1st1&#x2F;status&#x2F;1318558048265404420</a>
评论 #24856753 未加载
评论 #24851496 未加载
评论 #24849940 未加载
评论 #24849337 未加载
willseth超过 4 年前
The list should probably also include mypyc: <a href="https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;mypy&#x2F;tree&#x2F;master&#x2F;mypyc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;mypy&#x2F;tree&#x2F;master&#x2F;mypyc</a>
Twirrim超过 4 年前
Another one missing from that list is Graalpython, <a href="https:&#x2F;&#x2F;github.com&#x2F;graalvm&#x2F;graalpython" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;graalvm&#x2F;graalpython</a>. It&#x27;s in early stages of implementation, aimed at being python3 on top of GraalVM.
1wd超过 4 年前
One more: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;Pyjion" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;Pyjion</a>
评论 #24848583 未加载
Naac超过 4 年前
This article appear to be a list of python interpreters.<p>Not all of these were designed for speed,l. For example jython was also intended for Java&#x2F;python interoperability.<p>Some of the interpreters on the list haven&#x27;t seen updates in a while, or don&#x27;t support python 3.x
评论 #24848517 未加载
acomjean超过 4 年前
I tend to use Python for batch jobs and things where its speed isn&#x27;t that important to me. Am I alone in this?<p>When I reach for python its not for speed. Its because its fairly easy to write and has some good libraries.<p>Either its done in a few seconds, or I can wait a few hours as it runs as a background slurm task..<p>I feel like there is a group that wants python to be the ideal language for all things, maybe because I&#x27;m not in love with the syntax, but I&#x27;m ok having multiple languages.
评论 #24850234 未加载
评论 #24850450 未加载
ufo超过 4 年前
IIRC Psyco was a precursor to PyPy. Armin Rigo was involved in both.
评论 #24848636 未加载
arc776超过 4 年前
I gave up trying to make Python fast since to do so you give up what makes Python good and end up writing C&#x2F;Cython. On top of this, distributing Python is just... gross, at least for my use cases.<p>Eventually I found Nim and never looked back. Python is simply not built for speed but for productivity. Nim is built for both from the start. It&#x27;s certainly lacking the ecosystem of Python, but for my use cases that doesn&#x27;t matter.
zanellia超过 4 年前
In my opinion there is some potential there. Especially exploiting the increasing integration of typing-oriented features (i.e. type annotations) and the interest in using those to carry out static analysis (e.g. in mypy, but also Facebook&#x27;s Pyre and Microsoft&#x27;s Pyright and many other), it might be possible to speed up execution times a bit. This is especially true if we restrict the attention to a restricted subset of Python as, e.g., within domain specific languages. It might not make sense to entirely reverse engineer a language that was designed to be duck-typed into a statically typed one. However, for some domain specific applications I find performance oriented static analysis an interesting tool.<p>To make it more concrete, here is an experimental DSL for embedded high-performance computing that uses static analysis and source-to-source (Python-to-C, actually) code transformation: <a href="https:&#x2F;&#x2F;github.com&#x2F;zanellia&#x2F;prometeo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;zanellia&#x2F;prometeo</a>.
overgard超过 4 年前
I don&#x27;t know much about the other ones, but I think you&#x27;d have to say PyPy has been a success. Although to be honest, I don&#x27;t know why it would be better to modify CPython vs. just using PyPy -- the JIT speedup does come with some tradeoffs (memory usage, warmup times), so it seems better just to leave that decision up to the user?
thelazydogsback超过 4 年前
It amazes me that the stack-entwined implementation with the GIL remained the canonical version this whole time -- I would think that the Stackless version (or similar) would have been the default long-ago. This really should have made it worth it from a 2.x to 3.x version perspective, even if many people had to rewrite their extensions, and even if some monkey-patching were removed from the language in favor of more disciplined meta-programming.
评论 #24851914 未加载
zellyn超过 4 年前
Forgot one : <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy</a>
Boxxed超过 4 年前
Whatever happened to psyco? I remember it pretty much just working without any hassle and actually providing a noticeable speedup. All the mindshare is now on PyPy -- it&#x27;s received enormous amounts of engineering and still seems very rough around the edges.
评论 #24859544 未加载
评论 #24859534 未加载
est超过 4 年前
The HotPy listed by OP is done by Mark Shannon, the same person of today&#x27;s proposed 5x speedup<p>Also, some relevant old post:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17107047" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17107047</a>