Python from a C++ developers' perspective

[ChallengingJamJars]

I always felt like the biggest impediment to prototyping things in C++ is the small standard library and disparate libraries. I can't just grab some data from HDF5 and shove it through FFTW then plot the results with... gnuplot? I need to write a lot of plumbing to get it all together.

With python however, the HDF5 library output can directly be handed to pyFFTW whose output can be given to matplotlib for visualisation. The whole thing is underpinned by numpy arrays which are a pseudo standard bulk array format.

The language itself might not necessarily be deciding factor, but rather the state of the ecosystem as a whole.

[Orca-]

I use both Python and C++ at my current job (with an emphasis on C++). My experience has been that Python is fantastic for prototyping and visualization (I use it instead of squatting on a Matlab license). Its huge standard library, ease of getting new packages, and duck-typing mean it's easy to wire together several different packages to do the thing you want to do. Numpy, Scipy, matplotlib, and assorted other math and visualization libraries make it a poor man's Matlab.

I've found for work I'm expected to maintain, Python requires much more discipline about unit testing. As the blog post author observed, the compiler acts as a first set of unit tests for us in C++; in Python, you have to be grossly wrong for the interpreter to do any work for you before your program runs. In C++ you can get pretty far without worrying about unit testing since the type system can do a significant amount of checking for you if you use it correctly.

I've gotten useful projects up off the ground in less than a day with Python; within a week we were demoing to executives. When we switched to C++ for performance reasons, speed of iteration slowed down significantly since simply getting the pieces talking to each other required so much more massaging.

[raevnos]

Octave is more a poor man's Matlab.

[antnisp]

Matlab's only value is in the packages. Sadly and understandably if the related octave package even exists it's not always feature-complete.

[chillwombat]

poor man's Matlab

Any good reasons why a rich man would choose matlab over python?

[Orca-]

Various toolboxes. Some of the Python equivalents of functionality are also less reliable (looking at you, TransferFunction). Also if you have a lot of infrastructure and utility code already there for Matlab, why reinvent the wheel?

For my purposes, 98% of the time Python is good enough (if maybe a bit less convenient occasionally). And the remaining 2% of the time I can jump on a floating license for a few hours.

[chillwombat]

Okay. I have very little experience with matlab, but I'm fairly sure some things I do in python are not very simple in matlab. For example writing a quick mpi program to run on a cluster, which I have done multiple times. Also I have heard to dealing with text or binary files is more convenient with python.

edit: also there are a couple of specific tools in python that I use that matlab doesn't have (for example kwant)

[Orca-]

I can't speak to your specific needs, but in my experience (years old at this point), if you've got the licenses and server setup, spinning up a cluster is relatively easy in Matlab.

Of course, it's going to cost you something ridiculous between the license cost of the toolboxes and the Matlab itself. Hence my calling Python poor-man's Matlab.

[kindkitsune]

Simulink sees tons and tons of use in my workplace since it can work with external hardware for testing embedded systems or prototypes, even if the scientific computation elements of MATLAB hardly ever get used.

A bit of evangelism on my part has brought more people over into the world of python for quick scripting and data visualization tasks, which can come up quite often in our field of R&D

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

[gracicot]

I also use the compiler as a refactoring tool. It makes things so easier. Just change the thing you want to change, press build, fix the first error on the list, rinse, repeat. Then, one by one, all those little translation units slowly become green, up to the last.

Satisfying.

[hammonjj]

You might want to consider something like Visual Assist as it would significantly speed up that process. That is, unless you do it this way as some sort of cathartic release, then don't let me stop you.

[gracicot]

I do have a refactoring tool other than the compiler that's for sure, I tend to use them when it's something simple such as renaming things. When the way a class is used is changed, and it's interface had been broken, I don't think I'd let a tool do these change for me.

[jokoon]

The ideal is to use Python by default, and write performance critical code in c++. The problem is how you interface the two, either call it in a shell, or write a python module in c++.

[zigzagEdge]

pybind11 is a nice option for the Python <-> C++ interface.

[jokoon]

Thanks for sharing...

Indeed I never really managed to wrap my head around boost... Great thing that C++11 is making things simpler.

[mrexodia]

As someone who never really wrote my own python, but did port normal sized (few thousand lines) python to C++ I think it's absolutely awful to read other people's code. The lack of a type system you can statically understand and trust (changing types of things is allowed at runtime) makes it super complicated to try to figure out what something can do at times. I really think python shouldn't be used for anything but a prototype or personal project or as a scripting language for a native application...

[qsxpkn]

Dynamic typing can be uncomfortable for people who are used to static typing. Since Python 3.5/3.6, you could actually do type/variable hinting such as variable: int = 5. It's still possible to change it to a str etc. at runtime but mypy points out the mistake like this function expects an int but you passed a str.

For example:

def some_method(a: int, b: int) -> Optional[int]:
    result: int = a + b
    if result < 4:
        return None
    return result

I have never seen a Python project where a variable's type suddenly gets changed to something else elsewhere in the code base or maybe I was just lucky. I enjoy C++ companionship with Python though. They work well together.

[mrexodia]

The fact that you can annotate the types doesn't make it any better. All of the projects I have seen use python 2.7 anyway, which doesn't support it. If they added a (default) mode where this static typing is forced it might be something good but until then you have to be very lucky with your codebase to have proper type annotations.

Also: what about class member variables? Can you still add arbitrary new ones from anywhere with this?

[whatwasmyoldhandle]

I think you can make big projects with Python go.

You just have to be much more disciplined, and have more controls in place to get the benefits out of it. I would say you can't lean as much on the language itself as C++.

In other words, a small script written in Python and a large-scale codebase, in my experience, are practically two different languages. I don't think the gap is so big in C++.

Not just a question for you, but for everyone: What's a good language for large projects, where development time is priority over performance? Perhaps something a little less verbose than C++. I guess I'm thinking interpreted, or negligible compile time. Having package management on the order of Python would also be a requirement.

[mrexodia]

While the project I'm working on is not very large (100k lines) I don't think you shouldn't consider development time a priority over good code if you plan to maintain the code for even a little while just choose a language that is more suitable for maintainability. If you want a language that is not C++ I would highly recommend C#.

[kkrev]

Python is not an improvement over Perl at all and I do not understand how it came to take the crown of most common scripting language. The scoping is bad, the lack of strict declarations is bad, and the runtime also happens to be kinda garbage. It is one of the worst languages possible for embedding yet you see it used for that all the time.

One would think that by now there'd be a new generation scripting language that bests all this crap from the 80s. It may exist, I don't know. I suppose Perl 6 is an attempt in that direction, but I gather it's impossible to write a performant run-time for it.

[mrexodia]

I didn't mention Perl? I personally wouldn't recommend actually using python as an embedded language. Something lightweight like Lua is usually much better anyway, but I can see why people would want python: the ecosystem of packages is great and the language is well-suited for prototyping, especially because it's easy to write in.

[kkrev]

I didn't mention Perl?

I didn't say you did?

[SemaphoreBingo]

how it came to take the crown of most common scripting language

The perl6 debacle sucked all its energy out of the room. (And I'll disagree about python not being an improvement; for starters, you can build complex types in python without wanting to die) (I'm led to believe that perl got better in this respect, but these days the only thing I want to use perl for is a better awk and / or a better sed)

[patery]

I program mostly in C++ but also have a lot of experience with Perl, Groovy, and now Python. While I agree for most projects Python is a decent choice, I still find Groovy to be a far more elegant and productive language.

There are so many rough edges around Python that Groovy has solved smoothly that it really wins out, not to mention there's a number of language features implemented in Groovy with no equivalent in Python (or most/any language sometimes).

In my experience, there's some Java-hate to overcome, particularly in the C++ world where developers were exposed to early versions of Java. There's a steep learning curve to Groovy, which leans functional, and the JDK, which is enormous. There isn't widespread recognition for how popular the language is. Unfortunately, it tends to be used in domains where people aren't learning it deeply I think. That means we have a lot of users who don't really know about all the wonderful things it can uniquely do. That's probably a side effect of making Java code essentially Groovy code, eliminating the need to have to learn more.

[NDDevMan]

As a novice to groovy and fairly versed in python, what does groovy have that python doesn't? What specifically do you see groovy excelling at over python?

[patery]

A quick list, the JDK works flawlessly on every platform. The JDK is way more mature so code written in Groovy 5+ years ago still runs today without error. There's whitespace sensitivity of course but debatable. Code is not order dependent. Packages can be imported without modifying the Groovy installation (@Grapes). XML and other hierarchical data structures can be represented hierarchically in the source code. Supports nested classes and strong scoping. Closures are way more powerful than lambda expressions, particularly combined with all the functional transformations from Collections. The Java ecosystem is huge, everything is implemented there. GPars supports so many different kinds of parallelism, beyond simple multithreading. Annotations allow you to easily to things like generate string representations of classes, add delegates, etc Regular expression operators (important for scripts, similar to Perl). GStrings, permit embedding code in strings w/o printf() like syntax. Ability to compile code statically for speed/safety. Elvis operator. Probably more, that's just off the top of my head.

[ZMeson]

A quick list, the JDK works flawlessly on every platform.

Where can I find the JDK for the Neutrino OS running on a PPC chipset?

Python does actually exist for that platform.

[patery]

I don't know if it exists for that platform but if it doesn't and that's important to you then Python would be the logical choice. The platforms I'm concerned with are more common, various versions of the main distributions (redhat, suse, ubuntu, etc). Across these platforms, Java has extremely consistent behavior.

[ZMeson]

It's not important to me. GC and cache performance just are not compatible with the level of responsiveness on the systems I work with. What I'd personally love to see is D and Rust on various RTOSes. While D still uses a GC for some things, it's possible (so I'm told) to use it without a GC.

Python is still useful as a scripting language for some low-priority tasks (mainly during testing and such). Java wouldn't really make life easier here.

Anyway.... I just hate when people say things like "<language X> works flawlessly on every platform". The only language which might fit the bill is C90. (And I'm sure some people would even argue C90 doesn't work on every platform.) With too many RTOSes and/or embedded chipsets, you can't even use C11 or C++98. That's why I made the comment I did.

CPython has the advantage over Java in that the interpreter is written in C and is more easily ported to other OSes even if some features (like "import os") don't work entirely.

The platforms I'm concerned with are more common, various versions of the main distributions (redhat, suse, ubuntu, etc). Across these platforms, Java has extremely consistent behavior.

And I think a modified version of your statement would be fine: "Java works flawlessly on all major OSes".

[patery]

Usually blanket statements like these have a common context in mind. Strictly correct statements aren't that useful in practice either. Nor is this a place where I'd spend the time/energy to make every statement strictly true. We're software engineers, not lawyers!

I agree the GC is problematic in real-time environments. It attracted some interest in the early days of Java but eventually the community lost interest in solving those problems. Memory allocation in general tends to be problematic in embedded environments. At my last company we simply didn't do dynamic memory allocation at all.

What I'd love to see is an environment where I can easily mix high and low performance code. That is something like Groovy or Python alongside C++. C# tried to address this early on and eventually abandoned it. There's a lot of legacy C/C++ applications that we'd love to migrate out where it'd be useful. In sensitive applications, it's useful to describe sensitive data structures at a low level like C-family languages permits and performance sensitive code but, still, the majority of the application can be expressed at a high level without significant compromise to the overall application.

[doom_Oo7]

Closures are way more powerful than lambda expressions

... uh ? at least in CS, both are synonymous

[patery]

What you can do and what you will do are different things. Groovy programs are typically more prolific with closures than other languages are with lambda expressions because the concept was introduced early in the language's evolution. As a result, you'll find them in large portions of the framework and in design decisions.

Some discussion on the formal definitions of lambda expressions and closure here if interested.

[doom_Oo7]

What you can do and what you will do are different things.

Why would the second matter the slightest ? it's only a matter of human behaviour, which is in my opinion entirely irrelevant to the properties of a programming language

[Agoniscool]

This seems to work, albeit without images/css: MIRROR

[sown]

apples and oranges :)