Faster CPython Ideas – Issue Tracker for Faster CPython Project

226 点作者 patrick91大约 4 年前

17 条评论

patrick91大约 4 年前

Presentation from Guido van Rossum at the Python Language Summit: <a href="https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf" rel="nofollow">https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...</a>

评论 #27140684 未加载

评论 #27145456 未加载

etaioinshrdlu大约 4 年前

I updated a large Django project from python2.7 to 3.9 recently. Afterward, I was pleased that the app was both faster and used less than half the memory. It was somewhat surprising that the new version was so much better - most software seems to typically get only heavier over time!So, I take this as a good sign that progress will continue.

评论 #27143567 未加载

评论 #27149326 未加载

kzrdude大约 4 年前

This is exciting! So that we don't miss the main point: Eric Snow, GvR and Mark Shannon will be working for Microsoft to improve Python performance.In a way, it seems like Mark Shannon found someone to take him up on his offer on a plan for speeding up Python.

评论 #27141256 未加载

评论 #27141223 未加载

pca006132大约 4 年前

Just wondering, why is CPython a lot slower than JS? It seems to me that both languages are interpreted and comes with some reflection functionalities (like modifying object methods), but JS seems a lot faster in most of the benchmarks in <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>Edit: Why is this being downvoted? Is my statement incorrect or offensive to some people?

评论 #27143268 未加载

评论 #27142991 未加载

评论 #27142806 未加载

评论 #27142707 未加载

评论 #27147417 未加载

评论 #27143244 未加载

fdej大约 4 年前

I'd like to see optimizations targeting ctypes, or a successor to ctypes. I wish I could write elegant, performant C wrappers in pure Python. Right now the best choices are Cython, which is a hassle (separate, slow compilation, various warts), and ctypes, which is slow (and has some design problems of its own). Julia's ccall alone is a major selling point over Python right now.

评论 #27141828 未加载

评论 #27141358 未加载

评论 #27147220 未加载

评论 #27145478 未加载

评论 #27142998 未加载

milliams大约 4 年前

I posted the link to the first PEP yesterday (<a href="https://news.ycombinator.com/item?id=27134290" rel="nofollow">https://news.ycombinator.com/item?id=27134290</a>) I think this looks like a very promising project.

评论 #27140760 未加载

The_rationalist大约 4 年前

The python JIT that promise to get the highest throughput once maturity reached is <a href="https://github.com/oracle/graalpython" rel="nofollow">https://github.com/oracle/graalpython</a>

ForHackernews大约 4 年前

Is this going to incorporate the work done as part of <a href="https://blog.pyston.org/2020/10/28/pyston-v2-20-faster-python/" rel="nofollow">https://blog.pyston.org/2020/10/28/pyston-v2-20-faster-pytho...</a> or <a href="https://github.com/facebookincubator/cinder" rel="nofollow">https://github.com/facebookincubator/cinder</a> ?

bla3大约 4 年前

It's good to see that python startup time is an explicit goal. Empty scripts taking 10-100ms is a problem if you use python in Makefiles, where you can have thousands of invocations in a build. This wasn't considered a use case upstream cared about for quite some time. I'm glad to see this is changing. Here's hoping the acknowledgement will result in concrete gains!

评论 #27144115 未加载

morelisp大约 4 年前

Stage 2 should've been the selling point of Python 3.If there's really a 50% general speed boost sitting around in "normal" bytecode optimization work (and having read a decent amount of CPython I believe there could be), that's a criminal amount of energy over the past decade instead wasted dealing with what the type of a codepoint sequence should be named.

评论 #27153168 未加载

etskinner大约 4 年前

Why isn't this hosted at <a href="https://github.com/python/cpython/issues" rel="nofollow">https://github.com/python/cpython/issues</a> ?

评论 #27143906 未加载

guggle大约 4 年前

It really reminds me of this hilarious 2008 keynote by Cal Henderson: <a href="https://youtu.be/i6Fr65PFqfk?t=2255" rel="nofollow">https://youtu.be/i6Fr65PFqfk?t=2255</a>(relevant graphic: <a href="https://ibb.co/yV6bN9H" rel="nofollow">https://ibb.co/yV6bN9H</a> )

cpeterso大约 4 年前

Guido's slides in the repo mention speedup targets, but there is no mention of benchmarks. What is measured gets optimized, but which benchmarks are important for Python users? I'm sure Django users and Numpy users have very different performance bottlenecks.

评论 #27181856 未加载

frankreyes大约 4 年前

This project is dead already. Lua is 4x faster out of the box compared to Python (without LuaJIT!). Lua got fast by having ints and floats at the local side of values, not as a reference. That's in, the int and float value is in the variable itself, not as a reference with a pointer indirection. In Python, every time you do a=a+1 new memory allocation is made for the a+1 object. Java has the same performance issue with boxed types (new Integer), and this is why C# is faster in many benchmarks. (C# cheated with the hindsight advantage of knowing which were Java mistakes)

sergiomattei大约 4 年前

This is the most exciting development I've seen in the Python scene in years!Thanks, Guido and team!

punnerud大约 4 年前

Deleted. Posted the wrong place. Thanks for the comments.

评论 #27140786 未加载

obviousbob大约 4 年前

CPython's arcane constraints are holding it back - GIL, C API with a global interpreter instance, ref-counting, to name a few.PyPy is already a drop-in replacement for CPython with JIT and using a fraction of the memory.<a href="https://dev.nextthought.com/blog/2018/08/cpython-vs-pypy-memory-usage.html" rel="nofollow">https://dev.nextthought.com/blog/2018/08/cpython-vs-pypy-mem...</a>

评论 #27145681 未加载