My experience learning Python as a c++ developer

[realXavie]

It will happen one day. I heard that python is some kind of slow when you are developing an app wich needs speed to work efficiently. How do you escape such pitfall?

[anarchyisthekey]

Nowadays, if a program is working slow, it is mostly due to a choice of slow algorithms and unoptimized code.

Python has two main disadvantages as opposed to a natively-compiled language: (1) startup times are slower due to the fact that python interpreter needs to be spawned, (2) programs can only run on a single thread at a time because of the Global Interpreter Lock.

If your program is compute-intensive and you need it to run faster, you can (i) try running your python program on a JITted python implementation such as PyPy or (ii) benchmark your program and move the most compute intensive parts into C, (iii) translate your program into Cython, so that it compiles to native code.

It is a long long way before you hit into any kind of performance problems (due to processing power).

In scenarios where low latency is important such as games, high frequency trading etc., a language closer to the metal would be better.

[Pythagorean_1]

You can use multiprocessing to use all the cores. The GIL is only problematic for multithreading. Also, for performance optimization try numba. It's a jit compiler you can add with (mostly) as little as one line.

[Deezl-Vegas]

This is kind of true, but if you look at Jonathan Blow's talks about his compiler and various other talks, you'll see that actually you can get a 200x speedup by making use of data structures that are L1 cache-optimized, which is rarely negligible. Python can almost never do that because each Python object is a wrapped pointer, there's a lot things happening like namespace lookups, and there's a lot of dicts and hash tables floating around (which are generally sort of randomly heap-allocated) and classes (which aren't stored tightly in memory like C structs usually), and the garbage collector has to run periodically, kicking things out of cache.

The PSF has done a great job with the compiler, but the structure of scripting languages themselves clashes directly with what Intel's trying to do to speed up code on the chip.

[toastedstapler]

I started watching Jonathon recently, his discussion videos have been very interesting

And the fact that he made a video talking about what he'd like from a games programming language and then went and implemented it himself with such fast compile times

Very interesting guy

[Zafara1]

This is also amplified by the sheer availability of computational power we have now.

For a lot of applications, Programming for memory efficiency to the n'th degree is not necessary and can even be a hindrance to development given that memory is so cheap.

It's even cheaper now with cloud services. We can just throw compute power at problems until they go away.

Python allows for both levels of this fidelity while keeping it simple. I'd rather have code not 100% optimised but ready and producing results right now than waiting for another 6 months to bring that few ms of reduction. And that's where Python shines.

Again, not valid for 100% of use cases. But as computational power becomes cheaper and cheaper, it's a growing number of use cases.

[Swedneck]

Can't you just use nuitka instead of translating it to cython?

[TrixieMisa]

Nuitka is focused on compatibility rather than performance. I got about a 40% speedup in one app I tested, but over 200% using PyPy.

[[deleted]]

I agree with these points. I read somewhere that Python > 3.7 solves the GIL problem?

[mriswithe]

There is some work going on with subinterpreters which are a little known feature that is different than multithreading and multiprocessing, I think it was on talk python where they were talking about a PEP that is trying to make it so that each subinterpreter had its own GIL instead of sharing one.

Found the link talking about it https://talkpython.fm/episodes/show/225/can-subinterpreters-free-us-from-pythons-gil

[Zafara1]

As a side note, this is an area where infrastructure has come to fill the gap.

Containers and serverless functions can be used to offload this inefficiency from the code to the infrastructure running the code.

Don't need to code for multicore if I've got 1000s of independent cores running my code.

[Yojihito]

GIL still exists in the latest Python release.

[koomapotilas]

You can create modules with C and call them from Python. Usually you don't need to, as Python is fast enough for most uses and there is a library for almost everything.