[HN Gopher] Faster CPython (2021) [pdf]
___________________________________________________________________
Faster CPython (2021) [pdf]
Author : Radim
Score : 162 points
Date : 2022-01-23 16:14 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| devit wrote:
| Currently it's 50x slower than JavaScript
| ([https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...], look at n-body which
| is just straightforward math), and apparently they are looking to
| achieve 2x speedup and maybe 5x later, so not very useful.
| dralley wrote:
| You can't cherrypick the worst couple of results on the page
| and say it's "50x slower" when for most of the other benchmarks
| it's only 3-5x slower.
|
| Yes, tight numerical loops are going to benefit from JIT
| compilation, this isn't surprising. It's also not a very
| typical workload for either Python or Javascript.
| IshKebab wrote:
| It is 50 times slower. That matches all my experience. If you
| look at the "fast" benchmarks they're all just calling into C
| libraries.
| yehNonsense0 wrote:
| jdowner wrote:
| Yeah, I doubt it's ever going to catch on.
| hiptobecubic wrote:
| One-liner jokes are frowned upon here, but this was pretty
| good.
| bjoli wrote:
| If python gets some kind of JIT that kind of loop will fly.
| Tight loops and unboxed maths is a thing that JITs do really
| well at.
| aix1 wrote:
| I'd be very interested to see what JAX can do on this problem.
| dekhn wrote:
| https://github.com/google/jax-md
| [deleted]
| brokencode wrote:
| 2x or 5x is very useful if it speeds up common web server
| applications. A company with 4 servers can run 2 servers with a
| 2x speedup.
|
| Math-heavy benchmarks are not really representative of what
| Python is used for. They benefit from things like SIMD and
| aggressive inlining and fine-grained control over memory
| layout, etc. If you need that with Python, you can use
| something like NumPy or implement the hot path with a native
| language.
| vlovich123 wrote:
| Getting the interpreter to within 5x of a JIT is definitely
| better than "not very useful".
| humbleharbinger wrote:
| So tackling GIL is not on the table it seems
| code_biologist wrote:
| There's already progress on that from a different angle:
| https://news.ycombinator.com/item?id=29005573
| bjourne wrote:
| 99.9% of all software engineering is making it correct. The
| remaining 0.1% is about making it "fast". I.e. either reducing
| latency or increasing throughput. This is why Python wins. Once
| it is correct it is trivial to also make it fast.
| CharlesW wrote:
| > _99.9% of all software engineering is making it correct.
| [...] Once it is correct it is trivial to also make it fast._
|
| That sounds amazing but doesn't square with my experiences as a
| technical PM/PO. We might have different definitions of "fast",
| but generally speed-optimized code is _very_ different than
| prototype code (enough so that prototype "correctness" is non-
| transferable), more difficult to create in comparison to the
| prototype, and is often rewritten in a different language
| (Rust, C, assembly). For example, you're never going to write
| anything other than a toy video encoder in Python.
| bjourne wrote:
| Actually my experience from 20+ years of software engineering
| is that 99.99% of it is about correctness and only 0.01% is
| about performance. I added one order of magnitude to be on
| the safe side. Any non-toy video encoder takes advantage of
| hardware specific features so if you can't write it in Python
| you can't write it in Rust or C either.
| oweiler wrote:
| The thing is that other languages are as correct but leaps and
| bounds faster.
| asojfdowgh wrote:
| can't wait for this to be rather successful in hitting goals but
| then do nothing and languish like everything else
|
| It seems absurd to not mention the API upstreamed by the Pyjion
| attempt, especially in the context of optimizing bytecode /
| touching into machine code?
|
| I dunno, maybe I'm just perturbed by the amount of duplicated
| effort on this singular topic
| ivoflipse wrote:
| This is from the latest 3.11 alpha 4 release just this week:
|
| The Faster CPython Project is already yielding some exciting
| results: this version of CPython 3.11 is ~ 19% faster on the
| geometric mean of the PyPerformance benchmarks, compared to
| 3.10.0.
|
| https://pythoninsider.blogspot.com/2022/01/python-3102-3910-...
|
| So this is definitely not languishing as they are getting these
| changes directly into main for Python 3.11
| Alex3917 wrote:
| This is great, but at the same time 19% is still pretty far
| from 50%, and there are only ~3 months left until the feature
| freeze. It will be interesting to see how far they get in
| this release.
| wheelerof4te wrote:
| How long until some smartasses propose typing to be mandatory,
| because "speed"?
| makecheck wrote:
| While I think it is always good to see progress in the
| performance of interpreters, ultimately it is a mistake if you
| have something that _needs_ to be fast and you implemented it
| _entirely_ in an interpreted language (beyond just prototyping).
|
| You have to be prepared to factor out the key parts of the code
| into faster languages like C++ with bindings, if necessary. Or
| you can virtually do this, e.g. learn more about the standard
| library, make sure you are choosing things that actually are
| implemented natively underneath instead of in pure Python, etc.
|
| And sometimes, you find that the cause of a slowdown is far more
| fundamental (e.g. the _entire algorithm_ is not good, and you see
| huge gains by redoing it, even if everything is still interpreted
| code).
| pthread_t wrote:
| I've found that depending on that "key part", you can actually
| offload the task to another process (written in C/C++/Rust) via
| RPC. The end result was a significant performance improvement.
| IshKebab wrote:
| I work on a system like that and it just means you have to
| deal with a load of complicated FFI stuff and you end up with
| a C++ program that happens to have some slow parts awkwardly
| implemented in buggy Python.
| mattgreenrocks wrote:
| Using something like PyO3 for Rust/Python integration really
| helps with this, and you don't need the conceptual overhead
| of RPC.
| joshuamorton wrote:
| Interesting, I find that the conceptual overhead of pyo3
| (or cytpes) is often higher than making a local rpc
| boxed wrote:
| When you've done all that you're still left with performance
| wins you could get that are in the interpreter.
|
| I've worked on a system like that where it was just nothing to
| optimize really (anymore). It was just lots of code and there
| was no hot path to optimize.
| pizza234 wrote:
| > You have to be prepared to factor out the key parts of the
| code into faster languages like C++ with bindings, if necessary
|
| Stripe had the innovative idea of compiling ahead of time parts
| of the code (taking advantage of type annotations). I think
| this is a very interesting approach that may make usage of
| faster language unnecessary in a certain amount of cases.
| rich_sasha wrote:
| > ultimately it is a mistake if you have something that needs
| to be fast and you implemented it entirely in an interpreted
| language (beyond just prototyping).
|
| Agreed. Equally the faster the interpreted language, the less
| you need to offload, because baseline speed is good enough.
|
| Faster is rarely a bad thing.
| matteotom wrote:
| In my experience, the important part is sometimes that _faster_
| means _cheaper_. In many cases, 20% faster code means you need
| almost 20% fewer CPUs, which really adds up at scale.
| trulyme wrote:
| >... ultimately it is a mistake if you have something that
| needs to be fast and you implemented it entirely in an
| interpreted language (beyond just prototyping).
|
| Yes. However, this is exactly where Python (imho) shines. You
| get a convenient interpreted language which seemlessly
| interacts with highly optimized native libraries like numpy,
| scipy, xarray,... and of course ML frameworks (where impact of
| base language speed is negligable compared to the time it takes
| to train a model).
| xigoi wrote:
| Or you could just use a good compiled language for everything.
| ledauphin wrote:
| what happened to the recent work that was apparently a successful
| elimination of the Global Interpreter Lock?
|
| My work would become an order of magnitude easier if I did not
| have to use multiprocessing to get parallelism across shared
| memory.
| sigzero wrote:
| I believe that is a continuing WIP.
| tryptophan wrote:
| Ugh yeah, I hope this eventually happens.
|
| If some fork of python that has no GIL becomes popular, another
| python 3 situation could emerge with the community splitting.
|
| This "reference implementation should be simple and easy to
| read" is the dumbest part of python, unnecessarily holding it
| back imo.
| vlovich123 wrote:
| Yeah, that was my first thought. I think Sam Gross' work is
| being mainlined already so hopefully this is yet more
| improvements on top? Unclear.
| digisign wrote:
| There are several projects at work, any of which should land if
| they are successful.
| bilal4hmed wrote:
| This is a few months old....Have there been any updates since
| then? Seems like there are some perf improvements that are being
| added in to 3.11 and for some cases 2x faster than 3.10
|
| https://twitter.com/danielmilde/status/1484162983584575491
| maxerickson wrote:
| It's unfortunate how those results are presented. The worst
| result on the pybenchmark link is comparing a numpy based
| implementation to one that doesn't use numpy.
|
| If the latter _can 't_ use numpy or would be slowed down by it,
| that's a fair comparison, but it looks like they are just at
| different stages of optimization.
| erwincoumans wrote:
| Speed is one reason why Google is using Jax. With decorators,
| vmap/pmap it jit compiles your Python/Numpy code for
| fast/vectorized execution on GPU, TPU and CPU
| kanaffa12345 wrote:
| these two things have nothing to do with each other. jax
| doesn't compile numpy, it reimplemnts the api using `ufunc`. in
| general, every single numerical kernel is always mapped to kind
| of compiled code.
| erwincoumans wrote:
| It does for the user who is familiar with Python and Numpy.
| With some effort your Python and Numpy code becomes orders of
| magnitude faster. Telling that those two things have nothing
| to do with each other is missing the point.
| kanaffa12345 wrote:
| >missing the point
|
| facts
|
| 1. this is a thread about cpython. jax is as relevant to
| users of cpython as CUDA or OpenCL or whatever. jax cannot
| do absolutely anything with e.g. django.
|
| 2. for all intents and purposes all numerical code always
| runs in a lower-level implementation (C++, CUDA, XLA,
| whatever). so from that perspective, jax is just a
| convenient way to get from numerical python (i.e., loops
| and muls and adds) to kernels.
| erwincoumans wrote:
| I didn't claim Jax can accelerate Django, it all depends.
| A lot of our Python code is/was running partly in cpython
| and partly in extension modules such as Numpy.
|
| There are many ways to achieve faster Python execution.
| One is a faster cpython implementation, another is moving
| cpu intensive parts of the code to extension modules
| (such as Numpy). Yet another is to jit compile Python
| (and Numpy) code to run on accelerators.
| kanaffa12345 wrote:
| >jit compile Python
|
| given who you are (googling your name) i'm surprised that
| you would say this. jax does not jit compile python in
| any sense of the word `Python`. jax is a tracing
| mechanism for a very particular set of "programs"
| _specified using python_ ; i put programs in quotes
| because it's not like you could even use it to trace
| through `if __name__ == "__main__"` since it doesn't know
| (and doesn't care) anything about python namespaces. it's
| right there in the first sentence of the description:
|
| >JAX is Autograd and XLA
|
| autograd for tracing and building the tape (wengert list)
| and xla for the backend (i.e., actual kernels). there is
| no sense in which jax will ever play a role in something
| like faster hash tables or more efficient loads/stores or
| virtual function calls.
|
| in fact it doesn't even jit in the conventional
| understanding of jit, since there is no machine code that
| gets generated anew based on code paths (it simply picks
| different kernels and such that have already been
| compiled). not that i fault you for this substitution
| since everyone in ML does this (pytorch claims to jit as
| well).
| jstx1 wrote:
| And Instagram have their own CPython fork called Cinder -
| https://github.com/facebookincubator/cinder
| The_rationalist wrote:
| 1-6 wrote:
| Kudos to Microsoft for hiring Guido. I wish Google had kept him.
| [deleted]
| CalChris wrote:
| This slide deck matches up with this interview from _Talk Python_
| with Guido and Mark Shannon.
|
| https://www.youtube.com/watch?v=_r6bFhl6wR8
| realitysballs wrote:
| The speed of Python code creates its use cases. If it were to get
| faster higher volume applications could benefit but for my low-
| volume applications it works plenty fast.
| kmod wrote:
| Shameless plug: Python 3.11 comes out this October and is slated
| to be 10-20% faster, but Pyston is already available and is 30%
| faster. We do the things that are listed in this pdf, but also
| additional things that will probably never make it into mainline
| Python (such as adding a JIT)
|
| https://github.com/pyston/pyston
| edgyquant wrote:
| I respect your work here but CPython already has a roadmap and
| people paid to work on getting the experimental JIT into python
| in the next few releases.
| cuteboy19 wrote:
| Why won't JIT compilation make it to Python? Are the reasons
| technical or political?
| fault1 wrote:
| Guido seems quite anti-JIT.
| bjourne wrote:
| High-speed JITs are complicated and the CPython code base is
| meant to be kept simple. If you want JITted Python use PyPy
| (or JAX which is a JIT for tensor computation).
| Jasper_ wrote:
| The current CPython maintainers believe that a JIT would be
| far too much complexity to maintain, and would drive away new
| contributors. I don't agree with their analysis; I would
| argue the bigger thing driving new contributors away is them
| actively doing so. People show up all the time with basic
| patches for things other language runtimes have been doing
| for 20+ years and get roasted alive for daring to suggest
| something as arcane as method dispatch caches. The horror!
|
| This cements the CPython team as sort of a known "don't waste
| your time there" in PL research communities, distancing
| themselves from the people most likely and willing to help
| maintain their runtime.
| oblvious-earth wrote:
| The winds are probably changing with the CPython
| maintainers. I expect in the next few versions the efforts
| of PyJion and Faster Cpython will add a JIT API to plug in
| your own JIT in to CPython.
| ctoth wrote:
| So glad somebody finally said this. I've noticed this
| dynamic for years and it really is sad to watch. I remember
| reading over the community reviewing a large patchset
| someone had contributed a couple months ago and the amount
| of negativity was remarkable.
| hadcomplained wrote:
| Would you mind telling me exactly which patchset you are
| referring to?
| wswope wrote:
| Not OP but probably this one:
| https://news.ycombinator.com/item?id=28896367.
| xpressvideoz wrote:
| Python has always been adversarial to the PL communities,
| as seen in Guido's decision to limit the usefulness of the
| lambda function. He just didn't like the concept of long
| anonymous functions. I guess it is the inevitable
| characteristic of the typical "non-academic" languages,
| because I've also faced similar atmosphere in PHP and
| JavaScript too.
| Mawr wrote:
| > He just didn't like the concept of long anonymous
| functions.
|
| And rightfully so. If a function is long enough to need
| multiple lines, it's also long enough to be named.
|
| Complaints about this seem to come from the functional
| language circles, where chaining 10 .filter()'s,
| .map()'s, etc. together in a single line is considered
| not only normal, but desirable and idiomatic. Why bother
| naming the intermediate results, right?
|
| The ability to stuff a million operations on a single
| line that, for whatever reason, seems so coveted by many
| is quite clearly one of the least important aspects of
| language design. Vertical space is cheap and plentiful.
| Human brain capacity is tiny. Therefore, optimize for
| readability not clever one-liners.
|
| This is the big benefit of a BDFL, having single a person
| with good taste be able to veto bad ideas. Guido, for the
| most part, has good taste so Python's ended up quite well
| designed.
| Jasper_ wrote:
| Language design is a different field and specialty than
| implementation. Whether lambdas are multi-line or not has
| no bearing on the compilers and VM runtime specialists I
| know who tell others to stay away. Maybe the language
| designers feel similarly about the direction of Python, I
| don't know, but that's a separate community I have much
| less insight into.
| edgyquant wrote:
| But a JIT is already planned for a future release it's just
| there's a ton of other improvements they can do to speed it
| up first. See: https://github.com/markshannon/faster-
| cpython/blob/master/pl... where the plan is detailed.
|
| This is by a core python dev who is currently employed by
| Microsoft to enact this plan.
| Jasper_ wrote:
| It's possible things are changing. I just remember things
| like this, which was extremely frustrating at the time:
| https://lwn.net/Articles/754163 . Guido got visibly upset
| for this talk.
|
| In the last roughly 10 years, Google, Instagram, Dropbox,
| Facebook, and reddit all invested a lot of time into
| trying to make Python fast and was pushed away with harsh
| no's. There are dozens of forks and branches with basic
| optimizations that were rejected.
|
| I wish everyone the best of luck. But there's a side of
| me that's disappointed since this somewhat shows that
| it's only when these ideas come from inside the core
| maintainer team that they get acceptance. That's going to
| make it difficult to grow the team in the future.
| oblvious-earth wrote:
| > In the last roughly 10 years, Google, Instagram,
| Dropbox, Facebook, and reddit all invested a lot of time
| into trying to make Python fast and was pushed away with
| harsh no's. There are dozens of forks and branches with
| basic optimizations that were rejected.
|
| Is that true?
|
| The talk you link was about a very secretive fork of
| Python that Instagram was very adamant about not open
| sourcing until very recently (in fact it's not clear that
| what's open sourced is their full project).
|
| Other than that until recently all I've ever seen is
| either breaking the C-API or no clear commitment from the
| maintainers that this was a sustained effort to support
| and not just a drive-by complicated patch.
|
| In more recent times we have cinder, pyjion, pyston, and
| others. And CPython Devs are up-streaming either their
| work or their general approach.
| i80and wrote:
| I just want to toss out that Pyston actually gives a solid 2x
| speedup on my Python project. You've done amazing work. Thank
| you!
| dataflow wrote:
| Do you know when you might have Windows support? Since one of
| the main strengths of Python is its cross-platform support, but
| for Pyston I only seem to see Linux support.
| [deleted]
| dvlws wrote:
| The guy again gets his name in the headline. There has been no
| shortage of plans how to speed up CPython in the past 20 years.
| How about delivering a working product when it is done?
| brokencode wrote:
| His name lends a lot of credibility to anything he does with
| Python, and that's why this effort is notable. He is the
| founder and longtime BDFL of the language, and presumably knows
| what he is talking about when he says he can get big
| performance improvements.
| IshKebab wrote:
| I don't know if overseeing one of the slowest mainstream
| languages there is for decades gives me much hope that he
| knows what he's talking about when it comes to performance
| improvements.
| iqanq wrote:
| Ten years ago he didn't think Python was slow:
| https://lwn.net/Articles/486908/
| taylorius wrote:
| I read another commenter here mention that Python is 50x slower
| than Javascript. Now browser Javascript VMs underwent enormous
| speedup efforts over the last 12-15 years (Google chrome starting
| the race). Is there anything inherent to Python's design as a
| language (or any other technical reason) that prevents such a
| speedy VM being created for it as well?
| adgjlsfhk1 wrote:
| The big difference is that lots of python libraries use C under
| the hood, and a lot of internals of the language are leaked via
| the C api. It's a lot harder to do fancy things with a JIT when
| there are more people observing and depending on the internals.
| gravypod wrote:
| From a language design perspective I don't think there's much
| in the way of making up this ground. The hard part is not
| breaking any existing modules written in C/C++/Rust/etc that
| depend on the cpython ABI (memory layout and calling
| conventions of the runtime's implementation). There are jit
| compilers for python like pypy which are very fast (>5x they're
| attempting to gain here) but they often break things like numpy
| that have a lot of native modules.
| londons_explore wrote:
| Sounds pretty straightforward to get great speedups where no
| modules are used, and just make module calls slow (ie. you
| reconstruct the data structures the module will need on any
| entry to the module).
|
| Then release a new 'fast' module API, and all the performance
| critical modules will soon move over.
| gravypod wrote:
| It might sound easy but that would be a critical component
| of such a rewrite. Python's standard library is implemented
| using the same API so much of that would need to be
| rewritten. You then have the risk of introducing bugs, etc.
| This post is doing something similar. They're rewriting the
| internal implementation through progressive refactoring and
| will then look into more long term incompatible changes
| that can be wrapped in a translation layer. These projects
| are difficult as a lot of python code exists in the world
| and a minor change in behavior can have large unintended
| consequences due to Hyrum's law.
| faisal_ksa wrote:
| Yes, it's the GIL [1]
|
| [1]: https://en.wikipedia.org/wiki/Global_interpreter_lock
| nathancahill wrote:
| https://mail.python.org/archives/list/python-
| dev@python.org/...
| wk_end wrote:
| The GIL just prevents thread-level parallelism - which
| JavaScript also doesn't have.
| _bohm wrote:
| It depends on the runtime environment, no? For example,
| Node supports worker threads
|
| https://nodejs.org/api/worker_threads.html
| RussianCow wrote:
| Worker threads are share-nothing, closer to processes
| than actual threads.
| inglor wrote:
| Worker threads aren't share-nothing, you can share data
| through SharedArrayBuffer which lets you share arbitrary
| binary data.
|
| If they were share nothing, we probably wouldn't have
| shipped them.
|
| Source: I'm Node.js core and one of the people who worked
| on them
| RussianCow wrote:
| Sorry, I realized after posting that I should have said
| "share-nothing by default". There are ways to share
| memory with a worker, but it's explicit and opt-in via a
| dedicated API. It's not like in Python where you can
| arbitrarily change global state from any thread.
| zielmicha wrote:
| You can also share arbitrary binary data between
| processes by using shared memory (e.g. Python has support
| for this in multiprocessing.shared_memory module).
| kmod wrote:
| Yes, definitely. Python is much much more dynamic than
| Javascript -- the jump in dynamicness of Javascript to Python
| is about equivalent to Java to Javascript, and similarly
| requires a different set of techniques.
|
| The single example I typically give is that in Python you can
| inspect stack frames after they've exited! This has concrete
| implications on your VM design.
|
| Another example is that the multiple dispatch protocol for
| binary operations (such as addition) is sufficiently
| complicated that you generally cannot encode it into your
| compiler. We have been able to have a simplified version of
| that by building a tracing JIT for C, which is able to
| understand the dispatch protocol, but it is not always
| applicable.
|
| Source: I've been working on Python optimization for several
| years as part of the Pyston project.
| iqanq wrote:
| >The single example I typically give is that in Python you
| can inspect stack frames after they've exited! This has
| concrete implications on your VM design.
|
| How about an implementation of python that doesn't let you do
| fancy things like that that are not needed in production?
| Jasper_ wrote:
| The inspecting of stack frames is used by the logging
| library, and by most unit testing libraries. There are
| dozens of these small features which are challenging, and
| if you remove all of the challenging ones, you end up with
| something where pretty much no existing Python can run.
|
| People have tried, pypy started with that goal before it
| became clear it wasn't practical.
| akx wrote:
| I think logging inspects frames while they're still on
| the stack, not post-fact..?
| anticensor wrote:
| Unlike JavaScript however, Python is strongly typed.
| IshKebab wrote:
| Python's type system is not more strongly typed than
| JavaScript's in any way that makes it easier to optimise.
| Spivak wrote:
| Yeah but in practice basically all JS code in the wild is
| strongly typed since the community has long since decided
| that relying on implicit type coercion is a massive
| footgun.
|
| Also I think Python's truthy/falsey semantics make it
| dangerously close to being weakly typed.
| pjmlp wrote:
| Not more dynamic than Smalltalk or SELF, though.
| fault1 wrote:
| Or dylan or julia
| ravi-delia wrote:
| Is there any reason that Python's dynamicness (dynamicity?)
| is so much more of a hindrance than CL's? Is it just that CL
| is compiled?
| frozenport wrote:
| >> in Python you can inspect stack frames after they've
| exited!
|
| How does that work and what is it used for?
| orf wrote:
| Introspection is a gigantic issue.
| funklute wrote:
| Could you elaborate on that?
| orf wrote:
| There are a few different classes of introspection. The
| first is commonly used builtins like "isinstance",
| "callable", "getattr/hasattr" etc.
|
| The second is the inspect module that builds on that,
| allowing you to get the stack frames, inspect function
| signatures etc.
|
| The third is trackbacks, which need the stack and
| themselves are introspectable.
|
| The fourth is metaclasses (making dynamic classes at
| runtime).
|
| These are heavily used in Python, and are optimisation
| barriers. For example PyPy (Python with a JIT) disables
| optimisations when "inspect" is imported or used anywhere
| in the call stack.
| funklute wrote:
| How many of these "levels" (not to confuse them with
| actual classes) exist in javascript? Only the first one?
|
| (that said, I guess the fourth one (metaclasses) isn't a
| clear yes/no, since OO is very different in js)
| Jasper_ wrote:
| Hard to compare exactly with that classification, but
| JavaScript only has the first one, and arguably parts of
| the fourth one.
|
| metaclasses isn't really a major optimization hazard, it
| effectively boils down to hijacking the "class" syntax to
| instead run some custom code. It's used by things like
| dataclasses and the Django ORM to use class syntax to
| make a little DSL.
| pjmlp wrote:
| Smalltalk JITs do just fine with introspection and
| certainty Python does not have some magic feature that
| Smalltalk lacks.
| orf wrote:
| Despite being a totally different language based around
| message passing with no control structures?
|
| None of those are insurmountable, they merely make
| writing a JIT harder if you want to support them: it's
| hard to inline a function call if the inclining can have
| a visible effect.
| pjmlp wrote:
| That is the whole point, it doesn't get more dynamic than
| that.
| orf wrote:
| I'd say the lack of control flow structures and message
| passing would make it far, far easier to JIT.
| hiptobecubic wrote:
| cpython's specific implementation is a "feature" that many
| things rely on, but even without that, python's semantics
| are very dynamic and it's hard to unbox anything in a way
| that is guaranteed not to be observable.
| bjoli wrote:
| But there are other dynamic languages with crazy
| introspection that are among the fastest dynamic languages
| there are. Common lisp is one example.
| matsemann wrote:
| Since everyone knows Python is slow, no care is taken to make
| things faster in frameworks etc., since one assumes the users
| are fine with the speed. If "they wanted it to be fast, they
| would use something else, right"?
|
| So I stipulate that if the runtime becomes faster, those gains
| won't be visible to large swathes of code because python
| libraries do _lots_ of weird things under the hood.
| fault1 wrote:
| I thought this presentation by Armin Ronacher (the creator of
| Flask and Jinja) was very enlightening:
|
| How Python was Shaped by leaky Internals(2016):
|
| https://www.youtube.com/watch?v=qCGofLIzX6g
|
| See also this HN post (Attempts to make Python fast):
|
| https://news.ycombinator.com/item?id=24848318
| beagle3 wrote:
| Python is just too dynamic, and users do make use of it. There
| are JavaScript constructs that JITs give up upon, such as
| "with" - and this has steered JS programmers to avoid those
| constructs.
|
| Unfortunately, there is no Python subset people can stick to as
| such. But you can use e.g. TransCrypt to compile Python to
| JavaScript; the docs tell you about an efficient subset. It
| should be possible to build an efficient Python JIT for such a
| subset (and you sort of have one already through TransCrypt and
| JS)
| pjmlp wrote:
| Smalltalk, remap all instances of a into b across the
| complete image, no matter where they are being used or which
| classes they actually are instances of. a
| become: b
|
| It is a myth that only Python enjoys such dynamic
| capabilities, it happens to be a convenient excuse.
| ITB wrote:
| I personally think Python is nice to work with and I really like
| Django as monolithic web framework with no dependencies- a rare
| thing these days. But when thinking about long term projects I'm
| unable to reconcile things I like with the fact that Python is
| among the slowest modern languages. Why would I start with an
| unnecessary handicap?
| Mikeb85 wrote:
| Can't speak for Python/Django but I'm in the Rails world and
| the fact is on most Rails apps (even huge ones) the Ruby code
| isn't the bottleneck. IO and database operations are. You don't
| _need_ a fast language for the things Python (and Ruby, PHP,
| Perl, etc..) does.
| samwillis wrote:
| Also worth baring in mind that Shopify is a "monolithic"
| Rails app. That clearly shows it can scale enormously.
| remexre wrote:
| Though, they ended up writing a whole new Ruby JIT to deal
| with Ruby's performance, so clearly at some point the
| trade-off changes from "no systems programming, a highly
| dynamic language instead" to "hardcore systems programming,
| to make the highly dynamic language fast enough"
| Mikeb85 wrote:
| I mean, if you can get performance for free, why not?
| Doesn't mean Ruby was _too_ slow...
| hiptobecubic wrote:
| I think the takeaway here is that it was more sensible to
| _reimplement Ruby_ than to use something else. Think
| about that for a moment.
| jashmatthews wrote:
| Shopify got to huge scale first and then started
| sponsoring TruffleRuby and YJIT as research projects.
| gpderetta wrote:
| Every time I have to wait 10 minutes for pylint to slowly
| finish its job, I wonder if the IO-is-the-bottleneck crowd
| ever run their python code.
| OtomotO wrote:
| True, but depending on the service I personally would like
| efficient languages, not only dev time wise, but also runtime
| wise.
|
| Especially with regards to the environment.
|
| You may laugh all you want, the ever expanding internet
| should become way more resource friendly.
| nickjj wrote:
| > True, but depending on the service I personally would
| like efficient languages, not only dev time wise, but also
| runtime wise.
|
| I don't think this really exists today partly because of
| the comment you replied to.
|
| Rails, Django and Laravel are massively optimized for
| developer productivity to build web applications and use
| languages that have been around long enough where the
| community has created widely successful and popular
| libraries to implement mostly common features for things
| aren't included by default. Libraries that go beyond 1
| developer maintaining them in their free time.
|
| If you can build a web app and host it for $40 a month on a
| single VPS that can sustain tens of thousands of users and
| you can make a million dollars a year as a solo developer
| what incentive is there to switch to a faster language?
| Your secret weapon here is being able to build things
| quickly and not have to single handily develop a bunch of
| common lower level libraries just to build the app features
| you want.
|
| For when you need to scale out we have Kubernetes which
| generally works the same to scale out most types of web
| apps. It seriously (honestly) doesn't matter if your
| hosting bill is $10,000 / month instead of $3,000 / month
| when you have a team of 8 developers ($240,000 / month) on
| payroll and your web app is happily returning p99 responses
| in under 150ms while your business profits tens of millions
| of dollars a year. What does matter is how fast you can
| build new features while maintaining your app and finding
| qualified developers.
| capableweb wrote:
| > Especially with regards to the environment.
|
| > while your business profits tens of millions of dollars
| a year
|
| These two points from both of your comments don't really
| reconcile (today).
|
| Sure, if you're optimizing for "profits tens of millions
| of dollars a year" then go ahead and spend/receive as
| much money as you can and disregard all else, like the
| environment, employees health and so on.
|
| But, if we want to have sustainable companies, in terms
| of profit and impact on the earth together with it's
| inhabitants, then we need to go further than just
| considering how we can add that next million to our ARR.
| nickjj wrote:
| > These two points from both of your comments don't
| really reconcile (today).
|
| I didn't write both comments btw, the parent comment who
| I replied to is someone else who mentioned the
| environment.
|
| > Sure, if you're optimizing for "profits tens of
| millions of dollars a year" then go ahead and
| spend/receive as much money as you can and disregard all
| else, like the environment, employees health and so on.
|
| It's possible to be environmentally friendly, have
| reasonable server costs for an app built with Python /
| Ruby / PHP, keep employees happy and make major progress
| towards improving Earth. The place I work at is focused
| on clean energy management and the environment. It's a
| privately owned company so it's not my place to share any
| numbers but I can say we don't throw money at problems as
| a first line of action.
|
| For context, the company has been around for over 10+
| years and uses PHP (public info based on HTTP headers). I
| joined a few months ago as a full time employee after
| spending ~20 years being a solo developer doing contract
| work. I hope that sets the stage for how much I like the
| folks working there and how they run things. Also for
| context, I don't actively write PHP there. My role is
| focused on deploying their app(s) although I have
| developed some Python based services for them (I did
| contract work with them for a while before joining full
| time).
| hiptobecubic wrote:
| I really don't think the world is going to be saved by
| building your crud apps in rust instead of python.
| Consider instead what could be done if the company that
| is able to grow twice as fast has a charity matching
| program?
|
| Or, i don't know, imagine we tried to fix something that
| actually would cause a dent, like not encouraging
| everyone to buy new smartphones and laptops every year,
| not allowing international shipping to externalize the
| costs of burning "lowest imaginable quality" diesel, etc.
| This comment feels like saying "Turn off your LED lights
| when you go to bed!" while your neighbors are literally
| burning tires in their backyards.
| matsemann wrote:
| While a request itself can finish reasonably fast in a slow
| language, the amount of resources a single request consumes
| since python can't do multithreading is quite absurd. The
| python codebases I've worked on need an order of magnitude
| more servers to handle similar amount of loads, since each
| request is basically handled by a separate process.
| brandmeyer wrote:
| This is a widely-held belief, but it isn't true. Maybe once
| upon a time in the land of spinning rust that was true, but
| it certainly isn't now. Databases are fast enough that a
| scripting language frequently _is_ the performance
| bottleneck.
|
| https://techspot.zzzeek.org/2015/02/15/asynchronous-
| python-a...
| appleiigs wrote:
| Even if scripting language is the slowest, Ruby programmers
| say you need to include dev time in the equation which Ruby
| and Python optimize
| igouy wrote:
| Well, you would say that wouldn't you :-)
| hiptobecubic wrote:
| They get to say that because they are already done with
| their implementation and hanging out on HN for the rest
| of the afternoon.
| capableweb wrote:
| > scripting language frequently is the performance
| bottleneck
|
| I'm not sure I'd use the word "frequently" here, but I
| could just have a different experience. Most projects are
| boring CRUD stuff, and something else have always been the
| bottleneck before the actual language itself, most of the
| times different types of I/O but also just poor choice of
| algorithms/data structures. I don't think I've ever
| actually came across a situation where the language itself
| was the bottleneck of the performance, but I don't normally
| work super close to performance-sensitive projects as I
| said, mostly common web tasks.
| kolanos wrote:
| Every month or so I look around to see if there's a monolithic
| web framework in languages I'm interested that are effectively
| equivalents of Django, Rails, Laravel, etc. I've done a lot of
| non-webapp stuff with Go, for example, and would like to build
| full fledged webapps with a Django-like framework in Go. But
| nothing like that truly exists. I've found projects like
| Buffalo [0] that promise this monolithic experience, but
| they're still very much works in progress. Even Node lacks such
| a true monolithic web framework from what I can tell.
|
| [0]: https://github.com/gobuffalo/buffalo
| diordiderot wrote:
| Adonis for nodejs
|
| https://adonisjs.com/
| coldtea wrote:
| > _Why would I start with an unnecessary handicap?_
|
| Because "developer hapiness" and "speed of development" are
| also tradeoffs with other languages...
|
| In fact, if you're late to the market because you used some
| speedier language, it's often as good as not launching at
| all...
| xigoi wrote:
| Speed of code and speed of development are not mutually
| exclusive.
| coldtea wrote:
| They force different tradeoffs to be made in languages but
| also in development, so they kind of are.
|
| Obviously: if speed of development and speed of program
| were non-problematically compatible, everybody would always
| go for both (why lose speed, if you can have the same
| development experience)? But speed requires several things,
| like more careful algorithms and program design, custom
| solutions instead of one-size-fits-all libraries and
| frameworks, more care regarding memory usage, time spend
| for optimization, use of a statically typed language as
| opposed to a higher level scripting one, slower build/jit
| times (as opposed to interpreter), and so on...
| nooorofe wrote:
| For a bigger code base projects fixed typing contributes to
| speed of development. Add to it dependency management you
| will have clear win-win for something like Java over Python.
| piyh wrote:
| >slowest modern languages
|
| Horizontal scaling is going to be an issue eventually, no
| matter the language. You can serve tens of thousands of people
| off a single django server. Unless you're going to hit a growth
| limit at specifically 3-5x what a single vertically scaled
| django server can do, or you know for a fact that webserver
| compute is going to be the bottleneck, development speed rules
| all else.
| somethingAlex wrote:
| I'd agree, but I wonder how much faster writing a backend API
| in Django is compared to using node.
|
| I've written a lot of python outside of the web space and a
| lot of JavaScript in the web space and I can't think of a
| time I wish I was writing in python.
|
| Modern JavaScript has a really expressive syntax without the
| runtime performance hit.
| hiptobecubic wrote:
| For every comment like this, there is someone who would say
| the opposite. Why would I write in a language with the
| semantics of javascript when I could use python?
|
| I'd also argue that syntax-wise they are virtually the same
| language and not worth really comparing. It's not like
| either is ML.
___________________________________________________________________
(page generated 2022-01-23 23:00 UTC)