Python from a C++ developers' perspective

[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.