20 ms·
Python 3.11 is faster than 3.8
- deleted 4y ago[deleted]
- PaulHoule 4y agoThat n-Body simulation is a bad case for Python today in that you loop over the differential equation solver in Python. (It's like the very branchy semantic web and old AI stuff that I do for fun... I am migrating a lot of that to Java, PyPy helps a great deal but Java does a lot better.) If you are doing heavy matrix math, numpy runs at FORTRAN speed, tools like scikit-learn and Tensorflow also get high performance by doing the heavy lifting outside Python.
- nerpderp82 4y agoYou should give JAX a go. https://github.com/google/jax https://github.com/google/jax
- patrickkidger 4y ago+1 for JAX. Basically designed to be the successor to TensorFlow, and much nicer to work with. Strangely I've not seen it discussed around HN much but it's what I do 100% of my work in these days. Whilst I'm here: shameless self-promotion for Equinox and Diffrax: https://github.com/patrick-kidger/equinox https://github.com/patrick-kidger/equinox https://github.com/patrick-kidger/diffrax https://github.com/patrick-kidger/diffrax Which are neural network and differential equation libraries for JAX. [Obligatory I-am-a-googler-my-opinions-do-not-represent-your-employer...]
- brrrrrm 4y agoI feel like JAX usually comes up on PyTorch posts (in the same way PyTorch usually comes up in the comments on TF posts). I think the delta between JAX and PT on commodity hardware is just a little bit too small to really create much splash on HN.
- TheRealPomax 4y agoSounds like a case of "write the code to show what it should look like and show what numbers you get compared to the code they posted"? But remember that the exercise wasn't "to run the n-body simulation", or even "to run maths", but just to see how fast "plain Python" is with the release of 3.11 - using numpy and scipy, which rely on compiled code that they can hand work off to, would make any runtime value you get completely meaningless for the purposes of benchmarking pure Python =)
- bee_rider 4y agoClearly the solution is to add a jitter to Python that identifies code that looks like an matrix multiplication, and calls numpy instead.
- deleted 4y ago[deleted]
- PaulHoule 4y agoThe viability of Python for scientific work is predicated on using Python as glue code for code written in other languages. If pandas ran at the speed of Python people really would be using Julia or some other language instead of Python.
- TheRealPomax 4y agoAgreed! Which is why this is a benchmark of Python, not of "running scientific computations". Of course you're going to use numpy/scipy for that. Or you start using R, if you really care. This article isn't about what the code does, there are a million improvements to make if that's what we were looking at. It's about how fast a small program that uses some standard pure Python patterns runs today, compared to a few versions ago, with some "but what if not Python?". Because "you wouldn't write this code" applies to those examples as well. In JS you'd tap into a C-compiled native library the exact same way numpy/scipy does in Python. And in C, if you absolutely needed the fastest performance, the code would be full of micro optimizations and a sprinkling of assembler.
- systemvoltage 4y agoIt is still informative to see how slow native Python really is.
- bkanuka 4y agoI agree. This was honestly news to me - who very often uses Python for maths. However, I would never write the code as he did (instead I would rely on numpy/scipy). So I would also be intersted in a numpy version of the same test.
- adgjlsfhk1 4y agoNumpy would probably be even slower here. Numpy is good when you have large arrays, but it adds roughly .1 to 1 us per call in overhead.
- bkanuka 4y agoWithout validating anything myself, I was able to find this post https://hilpisch.com/Continuum_N_Body_Simulation_Numba_27072013.html https://hilpisch.com/Continuum_N_Body_Simulation_Numba_27072... which showed a simple n-body program sped up by ~670 times when moving from pure python to numpy+numba.
- adgjlsfhk1 4y ago2 things to notice: the first is that this is with 5 bodies while your link was with 1000. For 1000 bodies, numpy is a noticeable speedup (100x). For 5 particles (I used the same code as your article but adjusted the number of particles) numpy is 5x slower. Adding numba would make this fast again since it would remove the overhead, but at that point, just use a fast language in the first place.
- ReflectedImage 4y agoHow exactly would you write a gameboy emulator in numpy/scipy? It's sequential code with fiddly side effects. I know I've written one. But I'm generally curious if this is in-fact possible in someway.
- andybak 4y ago> numpy runs at FORTRAN speed Not everyone will be aware that this meant as praise. ;-)
- PaulHoule 4y agoYep. FORTRAN codes persist today because (1) the old school memory model of FORTRAN is fast, and (2) it is so easy to write numeric codes that do the wrong thing with rounding and numerical instability. There's a reason why Foreman Acton wrote a book titled Numerical methods that (usually) work. https://www.amazon.com/Numerical-Methods-that-Work-Spectrum/dp/0883854503 https://www.amazon.com/Numerical-Methods-that-Work-Spectrum/... Code something up in C, Haskell, oCAML or CUDA and you miss out on the 40+ years of experience people have had with a FORTRAN code from the 1970s.
- fragmede 4y agoA lot of physics simulations use FORTRAN for the existing libraries, and there's a way to run it on GPUs. It's not going anywhere.
- pbowyer 4y ago> (2) it is so easy to write numeric codes that do the wrong thing with rounding and numerical instability. Are you saying FORTRAN avoids these problems, or that it is prone to them? If the former, how does it do it?
- PaulHoule 4y agoIdeally, people who understood numerics wrote the code in the 1970s and it has gotten heavy use since then so if there are problems with numerical instability they've been detected and solved. Today somebody who doesn't know numerics frequently codes something up for the wrong reasons (e.g. to learn a new language, because they think the 1970s FORTRAN code is obsolete, ...) and never did the testing to know that the code they wrote is numerically stable or not. That is, you might think it is pretty easy to code something numerical up, and sometimes it is, but frequently you write something that's a little bit wrong and sometimes you write something that's terribly wrong, sometimes it isn't even wrong. It's not that FORTRAN is necessarily more accurate than another language, but that you can trust a code that has been around for 40 years and codes that have been around 40 years have been written in FORTRAN. --- As for the memory model I think about it the most when I write embedded programs for my Arduino. It drives me nuts that C diddles the stack pointer around meaninglessly when for most of the programs I write there are a small number of parameters that decide the size of all the arrays (like an old FORTRAN program) and local variables, recursion and all that are a source of problems and not solutions. The only reason I write C for that thing at all is that some of the programs I write are performance sensitive and I could get a bigger boost running the C code on an ARM or ESP32 than I could get writing AVR8 assembly and eliminating meaningless loads, stores and other activity that C does "just because".
- IshKebab 4y agoTo paraphrase: > That benchmark shows that Python is slow. If you avoid writing your code in Python it can be really fast!
- __mharrison__ 4y agoWow bun is fast! Would be interesting to see how NumPy or CuPy compare.
- bhaney 4y ago> Wow bun is fast! Relative to python? I ran the benchmark in the post with both node.js and bun, and running it with bun consistently took ~60% more time. That was with bun v0.1.10 though. I tried with bun v0.2.1 but it just crashed.
- moderation 4y agoNode (19.0.0) is quicker than bun (0.2.2) which is quicker than Deno (1.26.2) in my tests. (Edit: added Deno) mitata 'node sim.ts 10000000' 'bun sim.ts 10000000' 'deno run --allow-read sim_deno.ts 10000000' cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz runtime: shell (x86_64-unknown-linux-gnu) benchmark time (avg) (min … max) ---------------------------------------------------------------------------------- node sim.ts 10000000 803.35 ms/iter (773.08 ms … 848.1 ms) bun sim.ts 10000000 1.23 s/iter (1.19 s … 1.4 s) deno run --allow-read sim_deno.ts 10000000 1.37 s/iter (1.27 s … 1.69 s) summary node sim.ts 10000000 1.53x faster than bun sim.ts 10000000 1.71x faster than deno run --allow-read sim_deno.ts 10000000
- riffic 4y agoWaiting for Python 3.11 for Workgroups
- blitzar 4y agoIt is going to come on half a dozen or so double density disks.
- deleted 4y ago[deleted]
- llimllib 4y agoI wanted to see what the results for pypy would be. On my machine (very similar, a macbook pro m1 max): python 3.10: 52s python 3.11: 35s pypy 3.9.12: 10s (This test is basically a perfect test for JITs: one loop repeated many times) https://gist.github.com/llimllib/7af8144a92d3c2e1fc58be62988074e0 https://gist.github.com/llimllib/7af8144a92d3c2e1fc58be62988...
- deleted 4y ago[deleted]
- metadat 4y agoWhy is there such a dramatic performance gap / slowdown for 3.10 + 3.11 compared to 3.9.12?
- arc-in-space 4y agoThat's 3.9.12 of PyPy, not CPython
- qbasic_forever 4y agoThat's pypy 3.9.12, it has a JIT implementation to interpret python. The other two are standard CPython which doesn't JIT interpret the code.
- metadat 4y agoOops, thanks for clarifying.
- charlieyu1 4y agoDoes pypy support numpy now?
- llimllib 4y agoyes $ pip install numpy <snip building wheel> $ python --version && python -c "import numpy; print(numpy.identity(5))" Python 3.9.12 (05fbe3aa5b0845e6c37239768aa455451aa5faba, Mar 29 2022, 09:54:47) [PyPy 7.3.9 with GCC Apple LLVM 13.0.0 (clang-1300.0.29.30)] [[1. 0. 0. 0. 0.] [0. 1. 0. 0. 0.] [0. 0. 1. 0. 0.] [0. 0. 0. 1. 0.] [0. 0. 0. 0. 1.]]
- Timja 4y agoJavascript being 41x faster than Python seems a bit excessive. In my experience, having done quite a lot of dynamic language benchmarks, Javascript is about as fast as PHP and both are about 6x faster than Python. Has someone looked at the Python code used here, if it has any obvious gotchas?
- brrrrrm 4y agolet me know if you find anything! Happy to edit the post with a correction. For a little more information, this is using Bun 0.2.1, which uses JavaScriptCore (JSC), a part of WebKit which powers Safari. Since I'm running on an M1 Pro (Apple's ARM chip), there is probably somewhat of a benefit in using JSC.
- Spivak 4y agoIt’s a benchmark that is basically the ideal case for a JIT so it’s really Python vs. JS that got native compiled. I’m in no way criticizing the benchmark but that’s the reason for the starker difference.
- pedrovhb 4y agoThere is one. The author's implementation of `combinations` runs in quadratic time making copies of lists on each iteration. I replaced that for `itertools.combinations`, which uses an iterator, and found a pretty big difference: ~/p/not_that_slow python3.11 modified.py 5000000 -0.169075164 0.183753791 Time: 6.335 s ~/p/not_that_slow python3.11 main.py 5000000 -0.169075164 -0.169083134 Time: 48.515 s Other than this, the only modification I made is to include a `print` statement at the end to show the time taken. EDIT: That is not actually equivalent, my bad. The iterator is consumed and the execution ends early, I didn't realize the algorith iterated over it multiple times.
- inasio 4y agoNice speedup! I'd love to see a comparison between 3.8 and 3.11 of the same script, but using numpy
- ska 4y agowouldn't you expect numpy to mostly mitigate the differences?
- jhrmnn 4y agoThe boundaries are getting fuzzier. Implement this in Python _with JAX_ with little if any extra effort, run it on GPU, and you get performance you’d alternatively get only by writing custom CUDA kernels in C++.
- 3a2d29 4y agoI don’t think the borders are that fuzzy. Who has a C++ repo that isn’t in a low level language because it has to be? There is no production repo where python gets fast enough to replace Rust/C++. Still great to see improvements because there are repos where python replaces other languages.
- ReflectedImage 4y agoYeah but Python with Rust modules might be quite effective.
- N1H1L 4y agoEven cupy too. I have been using cupy for some of our own work, and it's so easy to do GPU based scientific computing, that it's funny now
- behnamoh 4y ago> JS is 41x faster than Python Except that Pythonistas often delegate such computations to libraries like numpy that achieve C-level speed. Python is supposed to be a glue language, JS is supposed to be a language that can run on browsers, so of course the two have different goals and performances.
- brrrrrm 4y agoI don't think there's much holding JS back from also being a glue language. JavaScript has certainly evolved from being only a browser language these days. The only request I'd have is more granular garbage collection (marking FFI memory as refcounted for more immediate destruction).
- xyzzy4747 4y agoTypeScript is better as a glue language than Python IMO.
- mg 4y agoIs the performance difference of Python and Javascript due to the language or due to the runtime? If one would compile both, the Python version and the Javascript version, to WebAssembly and execute that, how would the performance differ then?
- edflsafoiewq 4y agoPython and JS are basically the same language in terms of semantics.
- _ZeD_ 4y agowell, as long as both of them are descendant of modula 2 :) but no. while both languages share some similarities (dynamically typed, some form of "objects" and "classes") there are a lot of differences, both at "language level" and at "implementation level"
- edflsafoiewq 4y agoWhat are some important differences do you think?
- exebook 4y agoLexical scope and first class functions in JavaScript as a descendant from Lisp.
- dragonwriter 4y ago> Python and JS are basically the same language in terms of semantics. Python is dynamic class-based OO with multiple inheritance. JS is dynamic prototypical OO, though it has recently added convenience syntax implementing single-inheritance class-based OO on top of it. They are not the same.
- edflsafoiewq 4y agoIt's still redirecting to another object at runtime in both cases. The details are obviously not exactly identical but there's no great difference in the object model just because one is called a "class" and one is called a "prototype".
- UncleOxidant 4y agoWhat about Python 3.10?
- simonw 4y agoI'm really impressed with the performance improvements in Python 3.11. I ran a very basic benchmark against a local web application: I got 413.56 requests/second on 3.10 and the exact same code gave me 533.89 requests/second on 3.11. That's a big enough increase that I think it's worth actively upgrading projects. Usually I wait for a few months for things to settle in first.
- zitterbewegung 4y agoThe point of making python faster is not just making the above nbody simulation faster but also to improve the performance of when python is used as glue code to other more efficient systems. But, the language before has a bigger shift to making it faster due to the amount of resources it has now that are dedicated to making CPython faster similar to what happened with JavaScript. I hope CPython eventually is as fast as JavaScript.
- melling 4y ago“Besides strict typing and having a generally ugly syntax, C++ also requires ahead of time compilation.” What’s wrong with strict typing and ahead of time compilation as long as it compiles fast? Doesn’t this prevent many runtime errors that can occur in Python? Python is a higher level language than C++ so it requires less effort but newer compiled/typed languages offer more of what Python is good at
- klodolph 4y agoI have worked with very few C++ projects that compile fast, and my experience is that the errors in C++ projects are often more severe than the errors in Python projects. Even with modern C++ smart pointer style, I’ve seen all sorts of stuff like dangling pointers / use-after-free, buffer overruns, etc. All in code that had been reviewed.
- melling 4y agoYes, C++ was created in the 1980’s and a lot had been added … That’s why I was suggesting newer compiled languages incorporating some of what we’ve learned over the past 4 decades. eg type inference
- PathOfEclipse 4y agoIn general, the more work the type system is doing for you, the slower the compilation speed. Kotlin and Scala, for instance, both compile far more slowly than Java. I think even C# compiles very slowly compared to Java. You mention type inference, but type inference actually slows down compilation, and the more sophisticated the type inference, the slower the compilation! Similarly, Rust compilation speed is much slower than GoLang's, whose type system does relatively very little for you. I haven't seen exact numbers, but I've seen people say Rust and C++ have similar compilation speeds, and both are, in general, slow to compile.
- cestith 4y agoRust gives you so much more for the same compilation speed though.
- stuaxo 4y agoCan you test some alternate pythons: pypy, pyston, pyston-lite ?
- FpUser 4y ago>"C++ is a compiled language, which means that it lacks some of the convenience of Python and JavaScript. Besides strict typing and having a generally ugly syntax, C++ also requires ahead of time compilation." To me ahead of time compilation is a convenience that in many cases catches bugs before they present all their glory to a customer. As for "generally ugly syntax" - beauty is in the eyes of the beholder. I am for example multilingual and do not get hung up on syntax unless it resembles brainfuck. However having fn instead of function, not having brackets when supplying parameter list, having variables to use some special characters does not qualify for "beauty". It is just a different way of doing the same thing and often feels that it is done for the whole purpose of being different or half arsed attempt to make parsing simpler.
- andybak 4y ago> As for "generally ugly syntax" - beauty is in the eyes of the beholder. It's not entirely subjective. For example a language that is inconsistent in it's use of syntax could fairly be described as "objectively ugly".
- FpUser 4y agoYou just uglified nearly every language.
- andybak 4y agoOk. Maybe I should have qualified the example a little more. My point is - I don't buy that "language aesthetics are entirely subjective".
- FpUser 4y agoIf they are "objective" then people would not be creating "ugly" languages. Fact that they do shows that unless they are making brainfuck for purpose they believe their creations are not ugly. After that it only comes down to how many percent believe that language XYZ is a "beauty".
- phendrenad2 4y agoHow much faster? Should I update immediately or at my own convenience? Is this a game-changing speedup for my business?
- sdmike1 4y agoI'm seeing about a 50% speedup. It depends what you mean by game changing, but you should certainly see if 3.11 is a drop in replacement for whatever you are doing.
- ilovecaching 4y agoAt this point virtually everyone agrees that dynamic type is only good for scripting and cross-domain code, not for being robust software applications. Considerable effort has been spent over the years adding typing back to dynamically typed languages (Typescript, python has several). If you want to build real software, you should be looking at Go or Rust, not Python. They are already fast, they already have concurrency, and now with Go's generics it's safe to say that their type systems are exactly what are needed to build real software in 2022.
- deleted 4y ago[deleted]
- visarga 4y agoHow do I run the latest diffusion model in Go or Rust?
- ilovecaching 4y agoI said it was good for cross-domain code.
- ReflectedImage 4y agoYou can build robust software applications with Python. It just needs different development practices. Using static typing with Python is a bit dumb imo. Basically you write a ton of 3k line scripts, have them talk to each other a message queue like RabbitMQ and have a SQL Server e.g. PostgreSQL server do all the heavy lifting for you. You can't do any program like that but 80% of programs that are written in businesses can be done like that. Typical CRUD stuff. And you can develop it at 3x times the speed then if it was done in a more traditional language like Java/C# etc.. Python is a powerful language if you use it for the right use cases.
- Shish2k 4y agoChecking for my own “benchmark”, a gameboy emulator in several different languages[0]; it’s CPU-bound but across ~3k lines of code, so slightly more representative of real-world apps than a single-function tight-loop microbenchmark: zig: Emulated 600 frames in 0.24s (2521fps) rs: Emulated 600 frames in 0.37s (1626fps) cpp: Emulated 600 frames in 0.40s (1508fps) nim: Emulated 600 frames in 0.44s (1367fps) go: Emulated 600 frames in 1.75s (342fps) php: Emulated 600 frames in 23.74s (25fps) py: Emulated 600 frames in 26.16s (23fps) # PyPy py: Emulated 600 frames in 33.10s (18fps) # 3.11 py: Emulated 600 frames in 61.43s (9fps) # 3.10 Doubling the speed is pretty nice :D Still the slowest out of all implementations though :P [0] https://github.com/shish/rosettaboy https://github.com/shish/rosettaboy EDIT> updated the nim compiler flags to build in release mode like most other languages, thanks @plainOldText!
- gw99 4y agoInteresting. On the trifecta of money vs pain vs speed, Go seems to be a reasonable compromise.
- Thaxll 4y agoIt's probably "slow" because of sdl and cgo not native Go code. A gb emulator doesn't do much actually, it's about fixed array, bit shifting, switch cases etc ... I ran a quick pprof and indeed it's spending a lot of time in cgo: Showing nodes accounting for 28720ms, 67.67% of 42440ms total Dropped 145 nodes (cum <= 212.20ms) Showing top 10 nodes out of 53 flat flat% sum% cum cum% 13080ms 30.82% 30.82% 16600ms 39.11% runtime.cgocall 4720ms 11.12% 41.94% 4750ms 11.19% main.(*RAM).get 2840ms 6.69% 48.63% 33070ms 77.92% main.(*GPU).tick 1970ms 4.64% 53.28% 3720ms 8.77% runtime.mallocgc 1450ms 3.42% 56.69% 1470ms 3.46% main.(*RAM).set 1160ms 2.73% 59.43% 41350ms 97.43% main.(*GameBoy).tick 1000ms 2.36% 61.78% 3160ms 7.45% runtime.exitsyscall 890ms 2.10% 63.88% 1610ms 3.79% main.(*CPU).tick_interrupts 820ms 1.93% 65.81% 850ms 2.00% runtime.casgstatus 790ms 1.86% 67.67% 5530ms 13.03% main.(*CPU).tick
- 4y ago
- nigerianbrince 4y agoWhat they don't tell you is that python 3.8 was slower than 3.3.
- outworlder 4y ago> Python is a popular but reputably slow interpreted language. _sigh_ Why do people still say that? 1. There are no interpreted "languages", only interpreters for said language. One can compile or interpret anything. 2. When Java didn't have a Jit, it was still called "compiled language", even though it was running bytecode, same as Python. I think this "interpreted" vs "compiled" distinction is an anachronism. Pure interpreters are almost extinct. > (Javascript) It's a JIT compiled language with far more investment Oh, so it's compiled now? It's indeed due to investment, it wasn't always the case. > C++ is a compiled language Or is it? https://root.cern/cling/ https://root.cern/cling/
- snicker7 4y agoI am not sure if the JS vs. C++ benchmark is really fair. Using unix "time" utility, you are also including the startup of the JS runtime.
- MR4D 4y agoThe actual title should be “Python 3.11 is much faster than 3.8” to match the page. That missing word is important.
- Retr0id 4y agoIndeed - I clicked expecting there to be some kind of catch.
- ehutch79 4y agoI see a lot of comments about how other languages are faster. Please think about your actual workload and take them with a grain of salt. For instance, for most web apps, you spend a large amount of time waiting on database responses. It looks nothing like the modeling the tests in the article do. Benchmarks are not typical workloads. Don't just assume because some random person on hn says zig is faster you should rewrite your business apps.
- PathOfEclipse 4y agoI've actually found this to be completely untrue in practice. Just about every web service I've dealt with in production, if not all of them, have been CPU bound. This is for a number of reasons: 1) Network speeds have increased dramatically compared to CPU speeds. 2) People don't optimize code very much. 3) Web apps tend to do more work per request than they did in the 90s. Regardless, I've never seen an app saturate it's network pipe, but I've seen plenty saturate all their CPU cores, including relatively well-tuned ones. For instance, I wrote a Netty-based reverse proxy app once, and while I got it to run far faster than the typical app in that company, it was still CPU-bound in all my tests.
- ehutch79 4y agoI'd argue a lot of web apps are just serializing to json, after doing minimal business logic that likely has to do db requests. Once again, I said to look at what your load actually is. If you're CPU bound, then yes, buy a bigger instance, optimize, or switch languages. It's like how if you are putting up a blog, you probably shouldn't be looking at running kubernetes clusters for just that blog.
- skrtskrt 4y agoYeah I’ve profiled slow Python apps before and it’s almost always serialization that’s the sticking point. Default implementation of date parsing in particular is really bad
- PathOfEclipse 4y ago
- verst 4y agoNow just waiting for the GitHub Actions runners to be updated with Python 3.11 (deployment next week - they deploy image updates weekly). https://github.com/actions/runner-images/issues/6459 https://github.com/actions/runner-images/issues/6459
- stabbles 4y agoEven a 2x faster Python still makes a terribly slow language. Improvements look amazing relative to old Python. But compare it to PHP, Javascript, Lua. Ok, it might be better than Ruby sometimes.
- weatherlight 4y agoI thought ruby is now faster than python. ( I know that wasn't always the case though)
- xmddmx 4y agoSemantic Versioning with numbers > 9 really breaks my brain sometimes - I read the headline as "Python 3.1.1 is faster than 3.8" - a performance regression - and thought "Oh no!"
- uranusjr 4y agoI’m still patiently waiting for Python to eventually decide to jump from 3.X directly to X+1
- verelo 4y agoPython is in its awkward stage, something like PHP in ~2008. It's not super fast, it's got a good following but the changes to the core api's cause breaking changes, it's being used for things that maybe it shouldn't be, and it's facing a lot of competition from other languages. I had to laugh a few months back when someone suggested we switch a newish project to python from PHP 8.1 because "python is built in C" and "it's better for multithreaded math functions". A lot of misinformation out there.
- mitchellpkt 4y agoAnecdotally: wow just by upgrading from python 3.8 to 3.11 I measured a speedup from ~90 sec to ~60 sec runtime (in simulation code that mostly manipulates python built-in numbers and container datatypes)
- mastax 4y agoFor a long time many of the .NET Runtime's most fundamental and performance-sensitive functions were written in C++. In the beginning the JIT wasn't fast enough, or C# didn't have good enough native interoperability, or it didn't have the tools to write fast code. As the years went on the JIT got faster, and more and more improvements were added to help write high performance C# code. Now there's a mass effort to port most of the runtime to C# to make it safer, more maintainable, and often faster. RyuJIT may not generate code as nice as LLVM but there's so much overhead calling into native code that there are gains to be had. Imagine the alternate timeline where numpy is removing some of its C function calls because Python is fast enough on its own. I'm not sure we can make it there from here.
- oakwhiz 4y agoTesting this out on a simple project. As a straw poll measurement, I was seeing 4.5 to 6 seconds on version 3.9 and 4.29 to 4.4 seconds on version 3.11. Definitely a noticeable improvement, for what it's worth.
- devmor 4y agoDoes anyone actually choose Python with speed as a defining factor? It's one of the slowest popular languages.
- girafffe_i 4y agoDoes someone have these times for more languages? Would be curious to see the performance of Java Rust Ruby W/e I can estimate by using the energy consumption of each language as compared to C (https://storage.googleapis.com/cdn.thenewstack.io/media/2018/05/3730357d-results-energy-time-and-memory-usage-screenshot-from-research-paper.png https://storage.googleapis.com/cdn.thenewstack.io/media/2018...) but real numbers are appreciated.
- DeathArrow 4y agoI wonder what the performance would be if the code would have been compiled with GraalVM.
- jensenbox 4y agoI would love to see the OP benchmarks with Taichi applied: https://github.com/taichi-dev/taichi https://github.com/taichi-dev/taichi
- throwawaygal7 4y agoI am very partial to python, but i have hit a lot of bottle necks with it. I find GO to be a reasonable intermediate, balancing ease of use and flexibility with some speed trade offs. I should probbably learn rust but it seems like a lot for writing web apps, and I could never get my head around lifetimes
- soobrosa 4y agoDoes anybody have a Cython benchmark for this one?