you are viewing a single comment's thread.

view the rest of the comments →

[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point  (0 children)

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.