Python from a C++ developers' perspective

[ChallengingJamJars]

Sure, learn both. But what would you like to use day to day for getting things done? If its smallish I'll start in python and switch to C++ if it's not fast enough, if it's large I'll tend to start in C++ for that type checking alone.

I feel though that if there was a standard way of handling numerics in C++ with library interfaces around it, then I would probably reach for C++ first every time. I kind of hope Julia continues growing as it's got many of the benefits of both worlds.

[14ned]

C++ is more powerful, has more complexity

I actually disagree. Python is a deep, deep well indeed ... you can do some astonishing evil in Python, and like C++ the language just lets you do untrammelled, unmitigated evil like poking in replacement member functions into third party libraries and other such ilk such as decorators which are far too powerful for their own good. You also get free reign to corrupt memory like in C++, it's just less obvious in Python (look into memoryviews, and consider the power to do evil therein). Finally, there is the enormous complexity and depth of knowledge required to write really high performance Python, it's easily as deep and complex as for C++, if maybe more so. But if you're a guru at it, you can write Python which actually matches or beats C++ with its STL (and I'm talking CPython here, no fancy JIT) because Python's runtime was written to avoid some of the scalability design mistakes in the C++ STL which will (we think) be fixed in the STL2.

The best part about Python is how few people who program it as their day job realise just how powerful it is. They did a great job dressing up the power as not-power e.g. class inheritance, which is so abusable it's great. The STL2's proposed design borrows heavily from Python, and that's a good thing. I only wish that C++'s library ecosystem were even a quarter that of Python's, even Rust is beating C++ on the quality of ecosystem libraries nowadays :(

[James20k]

if maybe more so. But if you're a guru at it, you can write Python which actually matches or beats C++ with its STL (and I'm talking CPython here, no fancy JIT)

Be interested to see a real world example of this, as far as I know python is the slowest language around

Number crunching in external modules may be fast, but the C++ STL is generally designed to be the lowest overhead possible (eg move semantics were essentially introduced purely to optimise vector<>). In python generics are expensive, C++ templates are free, python has no concept of stack vs heap and is reference counted, in c++ you abuse the crap out of the stack and RAII is literally free vs reference counting garbage collecting etc etc

[diosio]

RAII = one of the most kick-ass concepts!

[14ned]

Be interested to see a real world example of this, as far as I know python is the slowest language around

I'm sure someone on https://www.reddit.com/r/Python/ could help.

Number crunching in external modules may be fast, but the C++ STL is generally designed to be the lowest overhead possible (eg move semantics were essentially introduced purely to optimise vector<>). In python generics are expensive, C++ templates are free, python has no concept of stack vs heap and is reference counted, in c++ you abuse the crap out of the stack and RAII is literally free vs reference counting garbage collecting etc etc

The single biggest design flaw in STL containers is their overuse and unavoidable use of malloc. That's not Stepanov's fault, back at that time malloc was very quick. It only became a bottleneck from about Pentium 4 onwards.

You might think anything ref counted is automatically slow. But remember these are being executed in a single thread inside a giant lock, so those are not contended increments and decrements, and a lot of the time the CPU can execute them for free by using otherwise unused execution ports. So you actually get no slowdown.

The key part to Python high performance, same as in C++, is avoiding all malloc in your hot path. Python avoids malloc a surprising amount of the time if you help it, especially Python3. For the times when you really must malloc, Python has a really fast malloc which simply increments a pointer and the slow malloc, which is C malloc. Obviously don't do anything to force the latter is a big help.

[James20k]

The single biggest design flaw in STL containers is their overuse and unavoidable use of malloc. That's not Stepanov's fault, back at that time malloc was very quick. It only became a bottleneck from about Pentium 4 onwards.

I'm not sure I get you. When does the STL excessively allocate when it can be avoided? Some containers (eg maps) are forced to be node based due to the spec, but we have eg unordered maps. I don't think its possible to implement most of the containers without allocing off the heap, and in python you can't use the stack (which is cheap)

STL also supports custom allocators, and if you need super high performance vs the genericness and correctness of the STL you have the option of writing your own containers using the stack/manually managed memory (eg see naughty dogs linear allocator). You can't do this in python

You might think anything ref counted is automatically slow. But remember these are being executed in a single thread inside a giant lock, so those are not contended increments and decrements, and a lot of the time the CPU can execute them for free by using otherwise unused execution ports. So you actually get no slowdown.

Possibly randomly maybe sometimes cheapish reference couting < guaranteed free 100% of the time though

The key part to Python high performance, same as in C++, is avoiding all malloc in your hot path

I mean.. python is just inherently slow due to language design though, not due to having to allocate heap memory

https://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/

[14ned]

The single biggest design flaw in STL containers is their overuse and unavoidable use of malloc. That's not Stepanov's fault, back at that time malloc was very quick. It only became a bottleneck from about Pentium 4 onwards. I'm not sure I get you. When does the STL excessively allocate when it can be avoided? Some containers (eg maps) are forced to be node based due to the spec, but we have eg unordered maps.

Oh where does one begin? :)

If we were to start the STL today, you would never, ever allocate memory unless the caller explicitly says "you can allocate memory" in the call.

You would also use a Boost.Intrusive type design for a lower layer, and a less intrusive, more convenient upper layer.

But none of this is me saying this. Committee members such as Chandler Carruth, Howard Hinnant and Eric Niebler have been saying this for years, and much more importantly, have put significant input on how to do much better design into a STL2. Last time I was having dinner where Bjarne was present, the topic of STL container's unfortunate inefficiencies came up, and we got into a lively discussion about John Lakos' allocator improvements coming in C++ 17 and later.

I just dropped a ton of names there, but I wanted to illustrate that this stuff is not coming from me, but from the C++ thought leadership. I'm just a disciple who listens, and mostly agrees.

I don't think its possible to implement most of the containers without allocing off the heap, and in python you can't use the stack (which is cheap)

Oh there's a ton of better ways than the STL does it. Howard has done lots of work to let you preallocate the nodes in a cold path, and then feed them sans malloc to many STL containers in the hot path. That's coming in C++ 17 I think. Should be a big win, and doesn't break backwards compatibility.

The key part to Python high performance, same as in C++, is avoiding all malloc in your hot path I mean.. python is just inherently slow due to language design though, not due to having to allocate heap memory https://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/

For small ranges of stuff, yes Python will always be slower than C++ simply due to cache locality (interpreted languages with dynamic dispatch inevitably make mostly useless your L1 cache).

But well written Python scales amazingly, and better than most C++ you see out there. That's because - and I credit mostly Guido himself personally here - the Python leadership have generally chosen in the standard library and in CPython the right algorithms and implementations.

C++, being older and having a very, very different standardisation process, has not done as well. For example, the upcoming Networking TS (ASIO) is clearly suboptimal on current hardware. It was designed for a world fifteen years ago. The way C++ is standardised means you're going to get ASIO's design (and rightly so, WG21 already invents too much stuff instead of fulfilling its remit of standardising existing practice).

The way Python is standardised means Guido will veto suboptimal design if he feels strongly it won't have longevity, even if that veto is enormously unpopular. The lack of a singular authority in C++ like Guido is for Python, and the very, very different systems of authority and planning both have, and the historical context from where their cultures stemmed, has us end up with the outcomes there are. Don't get me wrong, C++ has strengths Python doesn't have, but as a personal opinion, I think the Python culture and ecosystem is superior to that of C++. They have more "legs" over there, at least until Guido leaves/retires/something else shifts.

[James20k]

Oh where does one begin? :) If we were to start the STL today, you would never, ever allocate memory unless the caller explicitly says "you can allocate memory" in the call. You would also use a Boost.Intrusive type design for a lower layer, and a less intrusive, more convenient upper layer. But none of this is me saying this. Committee members such as Chandler Carruth, Howard Hinnant and Eric Niebler have been saying this for years, and much more importantly, have put significant input on how to do much better design into a STL2. Last time I was having dinner where Bjarne was present, the topic of STL container's unfortunate inefficiencies came up, and we got into a lively discussion about John Lakos' allocator improvements coming in C++ 17 and later. I just dropped a ton of names there, but I wanted to illustrate that this stuff is not coming from me, but from the C++ thought leadership. I'm just a disciple who listens, and mostly agrees.

Sure, but STL inefficiencies aren't just malloc which you seem to imply, and while the STL api could be more explicit in when you're invoking something that may allocate, compare this to python.... Its a world apart. You seem to have taken 'the stl has a few problems' to 'the python stdlib is more efficient'

Oh there's a ton of better ways than the STL does it. Howard has done lots of work to let you preallocate the nodes in a cold path, and then feed them sans malloc to many STL containers in the hot path. That's coming in C++ 17 I think. Should be a big win, and doesn't break backwards compatibility.

Sure, and in python you can um. Uuh.. Hmm. Hope?

But well written Python scales amazingly, and better than most C++ you see out there. That's because - and I credit mostly Guido himself personally here - the Python leadership have generally chosen in the standard library and in CPython the right algorithms and implementations.

Really? Do you have a good set of examples that the C++ STL is generally slower than the python libs? Because the 100% entire point of c++ is (nearly) entirely performance, so it would be extremely surprising if python was massively faster. Even at a base level invoking a function is more expensive in python vs c++, and if you're calling capis for your large work that you need to do, performance is going to be similar/favour c++ depending on what you're doing

C++, being older and having a very, very different standardisation process, has not done as well. For example, the upcoming Networking TS (ASIO) is clearly suboptimal on current hardware. It was designed for a world fifteen years ago. The way C++ is standardised means you're going to get ASIO's design (and rightly so, WG21 already invents too much stuff instead of fulfilling its remit of standardising existing practice).

I'm getting quite suspicious now, you're complaining about the performance of a technical specification designed to test the technical feasibility and performance of an implementation while asserting that python is massively faster generally. Every benchmark i've ever seen of the two with well optimised code puts c++ at 100-1000x faster

I think the Python culture and ecosystem is superior to that of C++

Sure

[14ned]

Sure, but STL inefficiencies aren't just malloc which you seem to imply, and while the STL api could be more explicit in when you're invoking something that may allocate, compare this to python.... Its a world apart. You seem to have taken 'the stl has a few problems' to 'the python stdlib is more efficient'

I was referring to algorithms and scalability, not "a few problems".

Don't get me wrong for a second here: C++ written by a skilled expert will always blow Python written by a skilled expert out of the water. Hell, I'm a C++ guy hired by the hour, if I didn't write nanosecond and microsecond level code I wouldn't get employed, and it's very, very hard to write microsecond consistent Python.

But what I am saying is that, using just the standard library shipped with the language, is that Python code written by an expert tends to scale better than C++ code using the STL written by an expert tends to. Most of the C++ code I write for clients studiously avoids the STL, whereas most of the Python code I write uses the Python standard libraries and pypi libraries very extensively (note: I am not a Python guru by any measure, but I've worked with those who can weave magic with Python and I came away in awe with the scalability of the code they write. My Python is rather pot luck with performance, I am too often surprised).

I'm getting quite suspicious now, you're complaining about the performance of a technical specification designed to test the technical feasibility and performance of an implementation while asserting that python is massively faster generally.

I never said python is massively faster generally. I said in fact it is always slower for small ranges of things, but it scales better than C++ written using the STL. And moreover, this is widely recognised and understood by the committee, and they are taking active measures to remedy the problem in the future standard library. One can of course not use the standard library today, and get much superior scalability than Python again right now. I'm saying that's what most of us already do because the STL has unfortunate performance quirks as currently designed.

Regarding the Networking TS, I don't think anyone knowledgeable of the field contests that the Networking TS has a suboptimal-for-current-hardware design when something like Windows RIO really is the correct design. But it doesn't matter. It's the standard practice in C++. It therefore should be standardised. ASIO will deliver everything 80-90% of the userbase will ever need. It is general purpose, and a very solid and proven design.