I'm not sure this is entirely noteworthy unless you somehow think CPython has a JIT. Would be much more interesting to compare to pypy.

Function call is a well-known weak point of cpython, even amongst all its other weak points performance-wise.

It's hard to express how utterly uninteresting and useless TFA is, and if its author is surprised by the result… really the only component this tells us about is the author.

> Would be much more interesting to compare to pypy.

I'm not sure it is more interesting at all, let alone much more, but here are the results on my (obviously much slower than TFA's) machine:

    > python3.9 --version
    Python 3.9.1
    > python3.9 fib.py
    8555.904865264893 ms
    > pypy37 --version
    Python 3.7.9 (7e6e2bb30ac5fbdbd443619cae28c51d5c162a02, Jan 15 2021, 06:03:20)
    [PyPy 7.3.3-beta0 with GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)]
    > pypy37 fib.py
    715.0719165802002 ms
    > node --version
    v14.15.4
    > node fib.js
    247.19056797027588 ms

"Obviously this isn't the most comprehensive benchmark, but the results are surprising to me."

I fully agree with this and I learned something new about cpython's weakpoints today!

If you want to get ultimate performance from Python then write a C function...

If you want to inform me about runtime performance then show me how the language runtimes are spending cycles. If you wish to convince me about a language being great then tell me about the engineering effort to create and then run something in production.

I still prefer python over node though, but I can't deny the reality.

  pypy test.py 

  node test.js      
                 

  python3 test.py     
       

Node still wins by a healthy margin.

638.8082504272461 ms

And why doesn't python's default runtime environment obviously come with a JIT then? I think they should absolutely go for it, given the huge user base of python.

Reasons like "but named functions can dynamically change" are not applicable, since JS has those same properties and can do it. They could start with optimizing the case where you call the same function over and over in a for loop.

An alternative python interpreter is also not the solution, normally what you have is the main standard python interpreter, and that is the one that should be fast, period.

1. because CPython aims to be relatively simple and straightforward by choice

2. because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT

3. because most of the userbase would not give a shit anyway, it has not exactly migratd en masse to pypy: much of the userbase sees and uses Python as a glue language, Python is an interface to optimised C routines without being a pain in the ass to develop in.

Sacrificing performance for core interpreter developer convenience may have been the right choice when Python was getting started; it's no longer the right choice today. Today it's short-sighted.

> because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT

We can have both a JIT and a "deep and extensive" (or more importantly, stable) native API, as demonstrated by node.

> because most of the userbase would not give a shit anyway

Actually a lot of the userbase don't use libraries with native extensions, are painfully aware of Python's performance issues, and are intensely interested in addressing them.

Yes, but not that native API. Designing a native API that doesn't create huge problems later is difficult. The JVM, .NET and V8 guys managed it (mostly) but the scripting languages generally didn't. Their API is just literally the entire internals of the interpreter.

Figuring out how to JIT code in the presence of native extensions that expect the implementation to work in exactly the same way it always worked is a research problem. The only people who have got close to solving it are the GraalVM guys. They do it by virtualising the interpreter API and also JIT-compiling the C code! They run LLVM bitcode on the same engine that runs the scripting engine.

It's a painful choice, and having to use numpy for everything that a loop normally could do but is too slow for, or discourage making functions because a function call is so slow, makes an otherwise elegant language less so

Python lets you do _far_ more shenanigans that Javascript does; and a lot of large libraries depend on some of that behavior. Breaking it would probably cause a new 2 -> 3 situation.

https://www.youtube.com/watch?v=qCGofLIzX6g&feature=emb_titl...

Armin makes great points about path dependence of API design and how the CPython API leaks into the Python language spec. But the features being discussed are actually obscure (example: slots) or intended for debugging (example: frame introspection), and most libraries don't have a good reason to use them. We're stuck in a loop: people talk about how Python is special and can't use a JIT because its internals are not JIT-friendly, so we don't have a JIT, so implementers continue to make choices that are not JIT-friendly - not because they want to, but because they have no guidance.

The JIT doesn't have to be amazing on day 1. What it does have to do is show a commitment and a path to performant code, and illuminate situations where optimizations turn off. There's nothing fundamental in Python's design that prevents a JIT from working; a small number of rarely used dynamic features (that most people don't know about and don't know that they can negatively affect performance) should not be used to hold up interpreter design.

Does JavaScript let you do this monstrosity of terrible code?

    Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class Dog(object):
    ...     def speak(self):
    ...             print("bark!")
    ... 
    >>> class Cat(object):
    ...     def speak(self):
    ...             print("meow!")
    ...
    >>> animal = Dog()
    >>> animal.speak()
    bark!
    >>> animal.__class__ = Cat
    >>> animal.speak()
    meow!
    >>>

    class Dog {
      speak() {
        console.log("bark!");
      }
    }
    class Cat {
      speak() {
        console.log("meow!");
      }
    }
    animal = new Dog();
    animal.speak();
    Object.setPrototypeOf(animal, Cat.prototype);
    animal.speak();

    bark!
    meow!

> An interpreter with a JIT is faster than one without. Especially when dealing with CPU bound work. Would be interesting to compare to pypy.

Sure, here is pypy:

  > pypy3 main.py
  282 ms

  > node main.js
  105 ms

  > python3 main.py
  2818 ms

  > node --jitless main.js
  998 ms

  > cargo run --release -q
  20 ms

.\php fib.php 1402.1289348602 ms

and with PHP8's new JIT opcache on:

.\php -dopcache.enable_cli=1 -dopcache.jit_buffer_size=200M fib.php 219.55609321594 ms

Overhead. Each operation translates to Python bytecode, and the Python interpreter performs a full loop of the core for each bytecode instruction.

The humble

    a + b

    LOAD_FAST a
    LOAD_FAST b
    BINARY_ADD

    fetch the bytecode
    jump to the handler
    access the function locals
    push the value for `a` (which TBF is just an offset into an array) onto the stack
    increment the bytecode index
    fetch the bytecode
    jump to the handler
    access the function locals
    push the value for `b` onto the stack
    increment the bytecode index
    fetch the bytecode
    jump to the handler
    popp both values off the stack
    dereference the type of `a`
    look for the pointer to the add method
    check if it's set
    call it with `a` and `b`
        which performs various runtime typechecks (e.g. are both parameters objects and integers) and does the actual addition
    push the result back onto the stack
    increment the bytecode index

    add r10, r11

An other component is that these are likely comparing apples and pears: CPython uses infinite-precision integer arithmetics. And due to not using a JIT it has no way to even remotely optimise any of that away. Infinite precision arithmetics are pretty expensive as they require lots of overflow checking.

You want to be either full JIT compiled code, or vice versa have as much interpreter functions, and libraries written in native code, and style the API to avoid loops.

So it can emit extremely efficient instructions based on this assumption, while CPython struggles along with infinite precision numbers.

Function calls will have a much lower overhead also since it will just be a single `call` instruction.

Python and JavaScript are scripting languages. Their advantages are being highly portable and relatively easy to develop and maintain. Performance has always been a weakness of both languages when compared to their pre-compiled siblings. That limitation is often mitigated by "gluing" together functionality implemented in a more performance-oriented language, but even then nobody chooses a scripting language because they expect it to be faster than the competition.

Besides, this is hardly a fair comparison. Many tech giants have competed in the browser space for years by hyper-optimizing their JavaScript engines. Comparing the performance of Node/V8 to that of CPython is like me comparing my strength to that of a child.

And if good optimizations can help run a small simulation in 1 minute instead of 2, multiplied by the number of python users, it is a lot of time gained.

And I suspect, the fib(n) situation is actually quite common. I mean, not everyone who writes python is a "real" developer, there are a lot of scientists who just want the computer to run their formulas, and they write them it the most straightforward way possible. They won't bother with high performance libraries and optimizing their algorithms just to save a few minutes, but they would appreciate if the language could make things a little faster.

And it doesn't matter in the way of "hey look, Python slow, use JS". But it is good information for Python developers and advanced users, the people who non-specialists rely on.

Real life tool manufacturers take "wrong" use into account. One of my preferred anecdote is the IMI Galil assault rifle, which has a built-in bottle opener. It was done because they noticed soldiers used magazines to open bottles, and it could cause damage.

Of course, it is not about choosing between a shovel and a spade, people who have a choice will use a hammer. But it doesn't mean we shouldn't do a favor to shovel bearers.

I completely disagree.

Your example of soldiers and their multi-tool use falsely conflates utility with necessity.

First, civilians generally don't have access to assault rifles (to even consider using it as a bottle opener) - i.e. soldiers are an edge case. Secondly, civilians who have direct access to bottle openers don't even need assault rifles - i.e. most people don't need edge-case solutions.

In the real world, when people want a hammer, they buy a hammer. They don't use shovels for hammering, unless they're forced to use one, or have no other option.

In the programming world all popular programming languages are virtually free. Programmers can choose and select between them. Modifying a language just so that it can do every specific thing (rather than the few things it is good at, or which its ecosystem is good at) is architecturally poor language design. And an excellent way to mess up the language - e.g. see PHP.

A tool should not need to accommodate to the whims and needs of every user. To use your analogy, if the shovel users have easy access to hammers, then they can grab the hammers when they need it, not force shovels into hammers.

To do otherwise is a stupid choice on the part of users, and is in no way a weakness of the design/utility of the language/tool itself.

The Galil magazine example has an obvious, easy-to-implement, low-cost solution with an obvious ROI. If that weren't the case, don't you think IMI would have just cautioned soldiers about potential damage to the magazines and instructed them to use a bottle opener instead?

For additional comparison, I quickly I rewrote the function in C (output and code below). The code was comparable in length and complexity (at least the fib(n) implementation was), but the relative performance is enough to make JavaScript blush. If you really wanted to do something as trivial as this, why would you even use pure JavaScript or Python to begin with? And if performance was a concern, why would you choose a reference interpreter like CPython?

Output:

    $ ./fib 35
    14930352
    68 ms

    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/time.h>
    
    int fib(int n) {
        if (n == 1 || n == 0) return 1;
        return fib(n - 1) + fib(n - 2);
    }
    
    int main(int argc, char *argv[]) {
        if (argc < 2) return 1;
        int x = atoi(argv[1]);
        struct timeval start, end;
        gettimeofday(&start, NULL);
        int n = fib(x);
        gettimeofday(&end, NULL);
        printf("%d\n", n);
        long unsigned int udiff = (
            (end.tv_sec - start.tv_sec) * 1000000 +
            end.tv_usec - start.tv_usec);
        printf("%lu ms\n", udiff / 1000);
        return 0;
    }

    const { performance } = require('perf_hooks');

    function fib(n) {
       if (n == 0 || n == 1) { return 1; }
       return fib(n - 1) + fib(n - 2);
    }

    function fibn(n) {
       if (n == 0n || n == 1n) { return 1n; }
       return fibn(n - 1n) + fibn(n - 2n);
    }

    var t0 = performance.now(); fib(35); console.log("fib:", performance.now() - t0);
    var t0 = performance.now(); fibn(35n); console.log("fibn:", performance.now() - t0);

    fib: 127.30008998513222
    fibn: 2134.1405459940434

(An equivalent version with Python on my machine: ~2657.3ms)

  JS with number              138 ms   (x1)
  JS with BigInt (eg. 35n)   2620 ms   (x19)
  Python                     3260 ms   (x24)

I prefer the JS approach.

I guess node.js might have the edge here with the necessary overflow checks in the addition. Both languages have to do them to fall back to either doubles or bigints respectively, but Node.js's JIT can probably do them faster.

  ~> python fib.py
  4825.7598876953125 ms
  ~> pypy3 fib.py
  514.7459506988525 ms

    @numba.jit
    def fib(n):
      if n == 1 or n == 0:
        return 1
      return fib(n - 1) + fib(n - 2)

498.46601486206055 ms.

second run:

89.19310569763184 ms.

For completeness, with njit:

    @numba.njit
    def fib(n):
      if n == 1 or n == 0:
        return 1
      return fib(n - 1) + fib(n - 2)

152.62889862060547 ms

second run:

86.35592460632324 ms

    from numba import jit
    @jit
    def fib(n: int) -> int:

  import time

  def fib(n: int) -> int:
    if n == 1 or n == 0:
      return 1

    return fib(n - 1) + fib(n - 2)

  t0 = time.time()
  fib(35)
  t1 = time.time()
  print(f"{(t1 - t0) \* 1000} ms")

  ~> mypyc fib.py

  ~> python
  >>> import fib
  332.64994621276855 ms

Numba wins and is about twice as fast as my most clever Cython code. Naive Cython is pretty bad, but more clever Cython is reasonably good (though not as good as numba).

I don't know that cpython would take advantage of mypy annotations and you can make a cpython program not python-compatible, but you don't have to.

If you can trust language benchmarks, you only get notable performance benefits when switching from JS to Rust/C/C++.

2. Why benchmark an O(2^n) fibonacci? It's basically benchmarking call frame creation.

3. A single order of magnitude is honestly not that impressive a speedup for JIT vs. no JIT. Might have a lot to do with the inefficiency of the recursive fibonacci func.

Also, to quote another poster:

    @numba.njit
    def fib(n):
      if n == 1 or n == 0:
        return 1
      return fib(n - 1) + fib(n - 2)

~86 ms

Which is...effectively identical to Node?

    @lru_cache(1000)
    def fib(n):
        if n == 1 or n == 0:
            return 1
        return fib(n - 1) + fib(n - 2)

I'd be interested to know if Node.js can do anything similar.

You'd have to also run the node version on your machine to know, as it's unlikely you have the exact same setup as TFA.

Python isnt made for performance, but for good code readability. Write clear, logical code for small and large-scale projects. It is also made by Guido to build applications in less time. Guido knows his language isnt the fastest, but thas wasnt the goal with Python.

Node.js is also made for other applications than Python. It's great for web developers to be in the "JavaScript everywhere" world. So it is easy for web developers to write backend and frontend code with the "same" language. It's also great for event's and "real time" communication with the (web) application.

Knowing that the most prevalent implementation of one is significantly faster than the most prevalent implementation of the other is useful information for someone deciding between the two for a project where performance is important.

Comparing alternative implementations of the languages, which are geared toward performance, would also be valuable. But simply knowing that, if your choice to use CPython is more-or-less arbitrary, you're leaving performance on the table, is valuable.

(Of course, as discussed in the top-level thread by @SuchAnonMuchWow, this particular benchmark seems to be comparing apples to oranges, and thus may not be of much value.)

Opening / reading / writing files, parsing args, making HTTP requests, etc. which are extremely common scripting operations are easier with Python, and the end result tends to be much more succinct thanks to its syntax (this applies to all Python code compared to JavaScript, but I'd argue it's especially valuable in shorter scripts).

Edit: didn’t exist at the time!

Python is my go-to because I know the ecosystem well and can go from zero to done with minimal effort and research.

Node has since (come into existence) and matured, and while it may be better/faster in some situations now, I haven’t encountered a project that has compelled me to switch.

I suspect the answer to your question boils down to a combination of: familiarity, preference, individual productivity, and pragmatism.

This will likely shift over time.

https://en.wikipedia.org/wiki/Node.js

But I guess the biggest differentiators are really the ecosystems and standard libraries. Node.js is certainly catching up, but Python has generally a better selection of high-quality libraries for tasks beyond the web.

What libraries or escape hatches to you actually use in your daily work that are exclusive to Python? The ones I'm familiar with would probably be OpenCV and the whole machine-learning family of libraries (sci-kit, spacy, tensorflow, etc).

IMO the opposite end of that particular scale is Perl.

Different tools are best for different jobs, for example if you need to run some basic NLP jobs pythons going to be much better.

However, it does make me wonder, why has python become to standard for data science? Is it Library support or purely community based?

Python is used at the top of the stack because it's an easy language to learn, you can get started fast, and, for places where performance is important - nothing is running in Python anyways.

Also interactivity and quick feedback cycle, stuff like Jupyter Notebooks (né IPython Notebooks, a spinoff from the IPython project), matplotlib, ...

Because it's glue, so its speed doesn't matter overly much.

> Is it Library support or purely community based?

That's a dichotomy which doesn't really make sense. Python has cultivated and attracted attention from scientific communities from the start: the matrix-sig (a special interest group focusing on array computing packages) was created back in '95 and a number of their suggestions were added as language-level conveniences (that continues to this day, `@` was recently added as the "matrix multiplication" operator).

This is feasible to reduce interpreter overhead considerably by using array programming:

c = a + b #This is valid Python code.

Where a and b are two same sized numpy arrays. Numpy typically handles the add in an optimized SIMD function.

I think Python is a good example of how being good enough is better than being awesome. And then it builds inertia through use and packages and friend of a friend recommendations.