[HN Gopher] Faster CPython Ideas - Issue Tracker for Faster CPyt...
___________________________________________________________________
Faster CPython Ideas - Issue Tracker for Faster CPython Project
Author : patrick91
Score : 202 points
Date : 2021-05-13 10:05 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pca006132 wrote:
| 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
| https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
|
| Edit: Why is this being downvoted? Is my statement incorrect or
| offensive to some people?
| ForHackernews wrote:
| I think mostly because Google has put a massive amount money
| and effort into making V8 faster.
|
| Performance has always been a lower-tier priority for cPython
| and other, faster, implementations (like PyPy) have not seen
| much mainstream adoption.
| BiteCode_dev wrote:
| Money.
| epidemian wrote:
| JS have been heavily optimized by browser vendors, fueled by
| the intense competition on the browser space, and the huge
| resources invested by companies like Google.
|
| IIRC Firefox 3 was the first browser to have what we would call
| a modern JS engine, with heavy emphasis on JIT compiling.
| Google Chrome soon followed and V8 dominated the JS perf story.
|
| Python doesn't have such fierce competition of implementations.
| And besides, it has the "escape hatch" of being able to
| implement performance-critical code paths as C extensions,
| which is what heavy-lifting libraries like numpy do.
| est wrote:
| > Python doesn't have such fierce competition of
| implementations
|
| Python have many competitions, but the language lack some
| sort of spec and the only reference is CPython.
| el_oni wrote:
| I think they were refering to a lack of interpreter
| competition. Sure there is pypy, jython, ironpython etc.
| But they arent competing. They are just used for different
| usecases.
|
| In the browser space their has been a lot of competition to
| make the fastest js runtime because it makes the browser
| faster.
| scatters wrote:
| CPython has a C API. Any Python object may at any time be
| passed into a C extension that expects to see all its
| introspectible attributes, nicely type-erased. This inhibits
| inlining, elision and monomorphization, all essential
| optimization techniques available to the JavaScript JIT.
| pansa2 wrote:
| > _It seems to me that both languages are interpreted_
|
| Node.js uses the V8 engine for JavaScript which isn't just an
| interpreter - it includes a JIT compiler.
| dec0dedab0de wrote:
| Yes, the JIT has got to be the biggest difference. I wonder
| how node compares to pypy.
|
| I think when GVR mentions "There's machine code generation in
| our future" that he is talking about a JIT
| throwaway894345 wrote:
| I suspect Node is still quite a lot faster than Pypy
| because the former benefits from v8 which is a well-funded
| project which doesn't have to worry about compatibility
| with the sprawling C-extension interface that CPython
| exposes.
| dragonwriter wrote:
| > Just wondering, why is CPython a lot slower than JS?
|
| Because no FAANG has ever seen CPython performance as a central
| element of an effort central to the future of the firm, and
| thrown money at it accordingly.
| obviousbob wrote:
| 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.
|
| https://dev.nextthought.com/blog/2018/08/cpython-vs-pypy-mem...
| fwip wrote:
| Pypy also has the GIL:
| https://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil...
| ForHackernews wrote:
| Is this going to incorporate the work done as part of
| https://blog.pyston.org/2020/10/28/pyston-v2-20-faster-pytho...
| or https://github.com/facebookincubator/cinder ?
| kzrdude wrote:
| 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.
| rqst wrote:
| Why do people in the Python community get so excited over
| announcements? I'd rather see working code, but no one cares
| about that in the Python universe.
|
| It is always announcements, talks, conferences and _if_
| something emerges it is a bit weird like the pattern matching.
|
| Meanwhile the Erlang people quietly produced a JIT without any
| advertisements.
| dragonwriter wrote:
| > Meanwhile the Erlang people quietly produced a JIT without
| any advertisements.
|
| Er, no, they didn't, they made plenty of announcements before
| the release, most of which even made their way to HN.
| coldtea wrote:
| > _Why do people in the Python community get so excited over
| announcements? I 'd rather see working code, but no one cares
| about that in the Python universe._
|
| Because almost everything you've seen as 'working code'
| started its life as an announcement.
|
| And because to coordinate and discuss future work, there
| would need to be some announcements.
|
| And because some announcements (based on the persons, e.g.
| here GvR is involved) or the funding (e.g. here MS is
| involved) or the specificity (e.g. here 3.10 timeframe is
| discussed) are more important than others.
|
| > _Meanwhile the Erlang people quietly produced a JIT without
| any advertisements._
|
| Good for them. That's maybe because much fewer care for
| Erlang (and thus for the advertisements) related to Python
| (which has a much larger dev base), so the advertisements of
| the former are posted fewer times and discussed by fewer
| people.
| HUSSTECH wrote:
| Just to add on the coordination point. Python has a large
| user base, and that's not to say larger user numbers equals
| better/superior. So the broadcasting of intention or
| direction is certainly welcome.
|
| Not only is it a large user base, but a varied one too.
| Flask, Django, FastAPI, Twisted...and that is just to name
| the web frameworks! We have scientific use, research use,
| cli tools. Perhaps in some cases end users (developers or
| not) of those tools may not be aware Python is the
| foundation of said tool.
|
| Anecdotally the Erlang users I've met have been incredibly
| knowledgeable and in tune with the language features and
| development. I find that pretty cool.
|
| In my opinion, an argument can be made that Elixir is the
| most prominent web framework for the language, so
| developers can just keep up with that and not the language
| if they wish. Compared to the Python ecosystem. As Erlang
| inevitably grows in popularity, it too may fragment.
| kzrdude wrote:
| This project has already submitted a few small changes into
| cpython, like https://github.com/python/cpython/pull/25069
| and https://github.com/python/cpython/pull/25729
| BiteCode_dev wrote:
| > Why do people in the Python community get so excited over
| announcements?
|
| When you like a tech, knowing people are brewing improved
| perfs on it is kinky. On Python, the motto has always been
| "it's fast enough", "if you want perfs, don't use python", "C
| extensions will solve this", "we don't want to make the main
| implementation complicated", "python dynamism and GIL make it
| a hard problem", etc.
|
| So in the python world, it's particularly big news,
| especially given that previous attempts (gilectomy, unladen
| swallow, first pyston...) all died.
| WesolyKubeczek wrote:
| > So in the python world, it's particularly big news,
| especially given that previous attempts (gilectomy, unladen
| swallow, first pyston...) all died.
|
| This is precisely the point you seem to be missing. All
| those things you mentioned were similar big announcements
| back in their day, and they all have just died by fizzling.
| What should be setting this one apart?
| BiteCode_dev wrote:
| Because Guido is paid to work on it.
| taland wrote:
| The only person with JIT experience listed there seems to
| be Mark Shannon. GvR may push through whatever is
| developed though.
|
| If that is cause for excitement can be seen when a
| product is finished.
| WesolyKubeczek wrote:
| When Guido was the BDFL (but whom am I fooling, everyone
| still will blindly accept a PEP from him and his opinion
| will still weigh a ton, steering council or not), he was
| pretty actively against any kind of bytecode-level
| optimization even though a lot could be done that way,
| citing "simplicity" and "readability". Most Python core
| developers have had pretty much a Pavlovian response to
| shut down any and all such discussions.
|
| I think they could get away with it for a while because
| none of the competing implementation would readily steal
| Python's darlings, namely NumPy/SciPy and Tensorflow. Now
| there is competition, and it can really push CPython away
| to being a niche "reference implementation", thus we are
| seeing these twitches.
|
| The track record of CPython core team in the last decade
| makes me very wary when it comes to bringing in such
| features. Ship it or it didn't happen.
|
| P. S. Microsoft once threw a large sum of money at
| Kenneth Reitz to work on Requests, anyone remembers how
| that story ended?
| dragonwriter wrote:
| > All those things you mentioned were similar big
| announcements back in their day
|
| Also, most of them released working code.
|
| So I guess we shouldn't be excited about that, either.
| BiteCode_dev wrote:
| For people googling, not that mark shannon:
|
| https://en.wikipedia.org/wiki/Mark_Shannon_(actor)
|
| That mark shannon:
|
| https://github.com/markshannon
|
| He tried to do hotpy in 2011, and trigger the idea of FAT byte
| code which I believed inspired the FAT python attempt of Victor
| Stinner.
|
| Now stinner is working on Hpy, dropbox on pyston, instagram on
| cinder, and pyjion just got a release.
|
| Looks like Python is going to get faster one way or another.
| sizediterable wrote:
| Dropbox hasn't sponsored Pyston development in quite a while
| https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-
| and...
| emily77 wrote:
| BlockFi offers crypto interest-earning accounts with up to 8.6%
| APY. This allows clients holding crypto like Bitcoin & Ether to
| earn compounding interest. BlockFi also offers low-cost USD loans
| backed by crypto. Access crypto capital without
| selling.https://yazing.com/deals/blockfi/safi68
| thefounder wrote:
| Spammer?
| milliams wrote:
| I posted the link to the first PEP yesterday
| (https://news.ycombinator.com/item?id=27134290) I think this
| looks like a very promising project.
| qteax wrote:
| 25-50% has been hoped for many times in the past 3 decades. I
| don't find that very impressive.
|
| CPython got big because of its relatively decent C-API and glue
| capabilities. 25% does not make a difference, decent C
| extensions have speedups in the order of 10-100 times (yes,
| _times_ , not percent).
|
| If I had a dollar for every time someone proposed a Python
| speedup ...
| BiteCode_dev wrote:
| This time, Guido is paid to work on it, and he is competing
| with cinder, pyjion and pyston.
| morelisp wrote:
| Mark Shannon's involvement is more interesting. There is no
| evidence Guido will be especially good at optimizing
| CPython performance (and arguably lots of evidence to the
| opposite). And as he's no longer BDFL it's not clear what
| power he really has to get his changes in if the Steering
| Council still shares his previous aesthetic preferences and
| not his current ones.
| klyrs wrote:
| > If I had a dollar for every time someone proposed a Python
| speedup ...
|
| Well, that's just the thing. Many have tried, many have
| succeeded, but their work hasn't been upstreamed so adoption
| is almost nonexistent. This is different. It's finally a
| mainline project. That's noteworthy, and _long_ overdue given
| the plurality of proofs-of-concept.
| pjmlp wrote:
| Python is feeling the pressure of not having a JIT on the
| box.
|
| Microsoft is reactivating their JIT project for Python as
| well.
|
| Their talk tomorrow:
|
| "Talk: Restarting Pyjion, a general purpose JIT for Python -
| is it worth it?"
|
| https://us.pycon.org/2021/schedule/presentation/52/
| aztec100 wrote:
| There have been many similar talks in the past decades. At
| some point Unladen Swallow was presented as "Google's
| project" (which is quite exaggerated).
|
| It looks more like Microsoft has JIT envy now that
| Instagram and others have open sourced (quite restricted)
| JIT projects and has to show presence again.
|
| I think every CPython JIT project will be full of corner
| cases in both performance and behavior, so it will add to
| the growing database of weird Python behavior that users
| have to memorize.
| pjmlp wrote:
| Indeed, it all boils down to the way Python community
| doesn't embrace such projects.
|
| Usually Python's high dynamism comes into the picture as
| main reason, however Smalltalk and SELF are just as
| dynamic, you can change the whole image at any given
| point in execution.
|
| In Smalltalk it suffices to send a _become:_ message to
| change the complete meaning of an object, and references
| to it, across the whole image.
| MR4D wrote:
| I think you are right to be skeptical, but this is GvR with
| Microsoft's money.
|
| So hopefully the combination of those two can make it work.
| [deleted]
| patrick91 wrote:
| Presentation from Guido van Rossum at the Python Language Summit:
| https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...
| antman wrote:
| Comments on the points being made based on my experience
|
| - without breaking anyone's code (did that for the print
| function etc and delayed py3 adoption for a decade but not for
| the most user requested feature which is speed)
|
| - No large PRs (how a 5x speedup can take place with small
| patches that no one figured out yet?)
|
| - a small team (not enough money, less risky if they tried to
| adopt other pypy-esque projects that are more advanced speed
| wise, a more comprehensive plan that would invite donations, I
| would certainly give. For this presentation I don't know)
| kzrdude wrote:
| I don't think "without breaking anyone's code" even needs to
| be a goal. Python has rolling deprecations and feature
| removals planned in the 3.x release series, and careful such
| feature transitions could be used to help JIT features or
| similar, too.
|
| To back up that fact: Python 3.10 will remove long-deprecated
| features, see issue tracker:
| https://bugs.python.org/issue41165 and What's new, the
| Removed section:
| https://docs.python.org/3.10/whatsnew/3.10.html#removed
| uluyol wrote:
| WRT large PRs, it doesn't sound like they expect all the
| improvements to be from small changes. I think the point is
| the code will be changed in increments so that even large
| changes (overall) will be easier to review and offer
| feedback.
| yjftsjthsd-h wrote:
| > without breaking anyone's code (did that for the print
| function etc and delayed py3 adoption for a decade but not
| for the most user requested feature which is speed)
|
| The Python 3 debacle is a beautifully worked example of why
| being backwards compatible is so important, and I can 100%
| sympathize with them not wanting to go through that again.
| axaxs wrote:
| Well, glad he's coming around. Years back he seemed to stand by
| the notion that Python wasn't slow, showing a toy example. I
| remember thinking it was just condescending, whether
| intentional or not.
| punnerud wrote:
| Deleted. Posted the wrong place. Thanks for the comments.
| Jiejeing wrote:
| You probably meant to send those links there:
| https://news.ycombinator.com/item?id=27127387
| BerislavLopac wrote:
| pyodide != pydiode :D
| sergiomattei wrote:
| This is the most exciting development I've seen in the Python
| scene in years!
|
| Thanks, Guido and team!
| etskinner wrote:
| Why isn't this hosted at https://github.com/python/cpython/issues
| ?
| _bohm wrote:
| Presumably development will be taking place on this
| organization's fork of cpython?
|
| https://github.com/faster-cpython/cpython
|
| Looks like they've also got a repo with some tools for
| profiling bytecode:
|
| https://github.com/faster-cpython/tools
| kzrdude wrote:
| Development is taking place in the main cpython repo and
| bugtracker, mark shannon already has a few merged PRs during
| the last month and a few more in flight. I.e the project has
| already started. See for example
| https://github.com/python/cpython/pull/25152
| bla3 wrote:
| 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!
| dongping wrote:
| Maybe you would want to check out Bazel as a build tool, since
| it uses a stripped down variant of Python called Starlark.
|
| https://docs.bazel.build/versions/master/skylark/language.ht...
| fdej wrote:
| 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.
| adsharma wrote:
| @fdej: what successor to ctypes did you have in mind? Other
| than the names (I prefer i8 over c_int8, but easy to work
| around) and lack of ergonomic interop with python ints, are
| there other issues you're aware of?
| adsharma wrote:
| Please take a look at py2many which does this. Looking for
| feedback.
| adsharma wrote:
| There is now a pull request for this:
|
| https://github.com/adsharma/py2many/issues/62
| ihnorton wrote:
| CFFI [1] is a step in the right direction, inspired by LuaJIT's
| CFFI. It originated from the PyPy folks and is supported in
| PyPy [2]; it's also supported to some degree by Numba [3]. I
| don't know what level of C call optimization is available when
| using the JITs, so I can't speak to the performance, but I've
| used it casually via CPython and was impressed by the API. That
| said, it has been around for a while and the traction seems
| somewhat limited -- I would guess because most people who have
| this kind of problem also need more than "just" FFI.
|
| [1] https://cffi.readthedocs.io/en/latest/index.html [2]
| https://doc.pypy.org/en/latest/extending.html#cffi [3]
| https://numba.readthedocs.io/en/stable/reference/pysupported...
| simonw wrote:
| I'm excited about WASM here.
| https://github.com/wasmerio/wasmer-python lets you call WASM
| binaries from Python, which means if you can compile a C
| library to WASM you can then call it from Python... without
| having to worry about introducing crashing bugs and security
| vulnerabilities thanks to the WASM sandbox.
| BiteCode_dev wrote:
| It's not nuitka main purpose, but it can produce a lib and
| speed up the code: https://nuitka.net/
| cpeterso wrote:
| 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.
| morelisp wrote:
| 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.
| The_rationalist wrote:
| The python JIT that promise to get the highest throughput once
| maturity reached is https://github.com/oracle/graalpython
| etaioinshrdlu wrote:
| 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.
| guggle wrote:
| > most software seems to typically get only heavier over time!
|
| It's often the case for end-user applications, but I find that
| most languages/runtimes tend to get better with time (and work
| of course !). There's a similar trend with the PHP runtime.
| cogman10 wrote:
| I can't think of a language/runtime that has actually gotten
| slower with time. The nearest I can really point to is the
| uptick in compile time that happens with languages like
| Rust/C++ every so often. That's not really a "language is
| slower" problem though.
| kzrdude wrote:
| rustc's trend the last twenty releases has been that the
| compiler is getting faster. I guess every dependency is
| slowly growing in size, offsetting this in your perception?
| The compiler benchmarks are of course held constant to be
| able to compare releases.
|
| See the perf website https://perf.rust-
| lang.org/dashboard.html
| MaxBarraclough wrote:
| That rule of thumb applies to the web too. Browsers keep
| getting faster, websites keep getting slower.
___________________________________________________________________
(page generated 2021-05-13 23:01 UTC)