Hacker News Reader

Comment by stefantalpalaru | Hacker News Reader

This doesn't look good for Python:

"Whenever possible, we use Python"

"When necessary, we use C++"

"As of right now, it ends up that about 75% of our code is C++ and 17% is Python (link) since it turns out that a lot of BIND 10 is performance-critical."

View on HN

Why doesn't it look good for python? As far as I'm aware, Python has never been advertised as a top-performance language, and part of the advantage has always been that you can rewrite performance-critical paths in c.

Adding to this, the fact that BIND is something pretty performance-intensive, I don't think this makes it look bad at all.

Because the stated goal was to use Python "whenever possible" and judging by the python2 bashing at the end of the article, the author is a true believer yet the best he could do was 17% of the total code.

This also clashes with the belief in the Python community that performance is not an issue because you just rewrite those few critical sections in C/C++. How's 75% as one possible definition of "few"?

What stupid comparison is this? Of course there will be more lines of code in C++, but i bet you that 10 lines of python do more then 10 lines of C++.

As another comment puts it: How much more C++ would there be without python?

>Because the stated goal was to use Python "whenever possible" and judging by the python2 bashing at the end of the article, the author is a true believer yet the best he could do was 17% of the total code.

Of the total code of a very specific application, with very specific performance needs.

For others applications, including servers, the ratio could vary widely.

If they're comparing by lines of code, the 17% that's in python may well contain most of the logic.

Bashing might be a bit harsh. Looks like the author is expressing legitimate concern about the proliferation of Python 2 over 3 and, let's face it, there are a lot of differences while 3 "is the future" as it says.

The percentages may or may not be simply a case of C++ verbosity, but without actually browsing the source, we shouldn't jump the gun on exactly what percentage of "heavy lifting" C++ is doing vs. Python.

>Why doesn't it look good for python?

Because it directly contradicts the "only 20% of your code is performance sensitive and the other 80% can be scripting language X" nonsense that scripting language apologists constantly parrot with no evidence. This is a good example of how scripting languages are in fact not well suited to application development, and should instead be used for scripting.

The question isn't how much Python there is relative to C++, the question is how much C++ there would be if there were no Python.

To put it more concisely: "only 20% of your logic is performance sensitive and the other 80% can be encoded in scripting language X leading to a significant reduction of your total code."

It doesn't lead to a significant reduction though, it is hardly any reduction at all. Look at their code, the python could be replaced with C++ at an almost 1:1 ratio.

I would argue that BIND isn't "merely" an application: it's almost kernel-level in what it needs to do and how it needs to respond. At a minimum, it's system-level—but definitely not application-level.

There is nothing almost kernel-level about it. It is an application. You seem to be trying to draw a very arbitrary distinction between applications and applications that you want to consider special for no particular reason.

Or you should use a fast Python interpreter instead of the slow one. The 20/80 (or 10/90 or so) is mostly nonsense in my experience too.

How many lines of C++ would be necessary to replace each Python line? Let's make a table:

Expansion Expanded 1 to 1: 75/ 17 --> 75% 17% 1 to 3: 75/ 51 --> 56% 38% 1 to 5: 75/ 85 --> 45% 51% 1 to 10: 75/170 --> 30% 67%

The LOC doesn't measure how many features are implemented in each language. If a language is more verbose or need more detailed management the same features will appear to be longer.

I can see what you're saying but it's worth contemplating what percentage of the total codebase that Python code would represent if it were replaced by C++ code.

I often convert python code to C++ and you'd be surprised how often the difference in loc is not that much. Certainly no hassle to do so. Not that I'm suggesting that one always should.

Several boost libraries are inspired by python and C++11 features all help to write C++ code that is surprisingly similar to python, with a bit of extra type sepcification. If you think otherwise I'd suggest you're probably thinking of the C++ of the 90s - a more C with classes, and not modern C++.

I often find it useful to develop and prototype in python and convert to C++. Most often I'm doing this because my python simulations can take days and the C++ versions hours. Often I find it is not just the performance critical areas, but it is easy enough just to wholesale convert the lot.

I often convert python code to C++ and you'd be surprised how often the difference in loc is not that much.

I agree, especially with C++11 and (besides Boost) Qt. It's often the header/code separation that makes things a bit tedious, having to keep function and method signatures in-sync. Of course, if you are template-land that is not that much of a problem.

Thanks, this is interesting. I'm thinking of getting back into C++ after being forced to work on (of all things) a C project. It's hard to know where to dig in, since actually working with existing code means not playing with C++11.

I'm working on a project right now where we're replacing a Qt interface written in Python (PyQt) with C++ Qt as it's way too slow (interface is really laggy), and other than things like having to occasionally delete objects manually (often, if you just add a widget to a layout, Qt does the deletion for you), it's pretty much a 1-1 mapping.

We're also replacing core op-graph and geometry processing from Python to C++, and again it's close to 1-1 - there's a bit of overhead in the loops - in our coding style we're caching begin iterators on the line before the loop, but other than that it's very close.

And the speed of the app is so much faster it's not even funny.

>in our coding style we're caching begin iterators on the line before the loop

Can you give an example of what this looks like?

  python:

  for face in mesh.faces():
  	faceCentre = Point()
  	for v in face.vertices():
  		faceCentre.add(mesh.getPoint(v))
  	faceCentre.div(len(face.vertices()))
  
  C++:
  
  std::vector<Face>::const_iterator itFace = mesh.getFaces().begin();
  for (; itFace != mesh.getFaces().end(); ++itFace)
  {
        const Face& face = *itFace;
  	Point faceCentre;
  	std::vector<unsigned int>::const_iterator itVertex = face.vertices.begin();
  	for (; itVertex != face.vertices().end(); ++itVertex)
  	{
  		const unsigned int& pointIndex = *itVertex;
  		faceCentre += mesh.getPoint(pointIndex);
  	}
  	faceCentre /= (float)face.vertices().size();
  }

So the C++ is longer, but you've got braces, and the references to the Face and unsigned int pointIndex are placed as a local variables, which makes debugging much easier - they could be inlined.

It's possible to get that down even more using more modern C++ - using auto variables and not declaring the start iterator on it's own line.

So yes, counting braces, it can be a lot more lines, but if you don't count braces, it's generally not that much more.

I guess what I'm asking is, why are you declaring the start iterator on its own line? What benefit does it have? Or does is just make the for loop line shorter?

Also, as of C++11 you can do this:

  for(const Face& face : mesh.getFaces()) {
  	Point faceCentre;
  	for(size_t pointIndex : face.vertices())
  		faceCentre += mesh.getPoint(pointIndex);
  	faceCentre /= static_cast<float>(face.vertices().size());
  }

Yeah, it makes the for line shorter.

We sometimes hoist the end iterator as well, as often g++ can't optimise out the call to .end() each iteration - it can if there's a ref to a const item and you call end() on that const ref, but otherwise, it generally doesn't as it can't guarantee the item hasn't been modified.

We're still stuck with CentOS 5.4, so g++ 4.1 for us as that's what we've got to deploy to (although we use ICC for production builds, building off the g++ 4.1 standard headers)...

Basically, we want top possible speed - if that means the code's a bit more verbose than it can be, so be it.

That's 163 vs 486 characters, so, as I expected you'd need about three times the amount of code to do the same thing in C++.

And just look at the difference in readability/simplicity. I can explain the Python code to my 12 year-old cousin, the C++ version though...

Point taken, but if by this metric the percentage replaced by C++ code is still bigger my original criticism still stands.

It could mean that you need more C++ to do stuff (or less Python code to do stuff, whatever your like).

What I'm saying is that "amount of code" is not a valid magnitude when comparing different languages.

In my experience converting some unmaintained Perl tools to Python, the Python version was almost as long as the Perl one, but it included more functionality, comments and error handling (I'm not criticising Perl here but the unmaintained code that I had to convert).

Generally you start with Python and 1) get the code correct (hardest part) and then 2) port the performance critical parts to C/C++. So even they ended up with 0% in Python, it wouldn't "look bad". You got the benefit in part 1.

(And as others have said, 17% of LOC in Python might still mean majority of the functionality in Python).

I don't think you are interpreting that correctly. Python is never pushed as "fast". That is exactly how I would use it. Python wherever I could and C++ (or whatever) when performance is crucial.

That is (the official/BDFL) Guido's stance on the matter too - whenever possible, use Python, but switch to C for computationally expensive tasks.

(https://plus.google.com/115212051037621986145/posts/HajXHPGN...)

Reply on news.ycombinator.com