Live data from Hacker News

Why is BIND 10 written in C++ and Python?

isc.org

111–120 of 136 posts

Re: Why is BIND 10 written in C++ and Python?

#111
post #48

Earlier quoted context omitted.

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++,…

>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::const_iterator itFace = mesh.getFaces().begin();
  for (; itFace != mesh.getFaces().end(); ++itFace)
  {
        const Face& face = *itFace;
  	Point faceCentre;
  	std::vector::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.

Re: Why is BIND 10 written in C++ and Python?

#112
post #106

Earlier quoted context omitted.

You don't have to use exceptions in C++. You can do stuff the same way as in C by checking the return pointer. I've worked on C++ apps that had built-in garbage collection (basically asset (geometry) paging) for huge amounts of data that would allocate/free/page on demand based on what was going on.

Sure, but then you can't use the standard library or any other libraries. Even a single exception sneaking into the codebase breaks everything.

We did - loads of Qt and std:: stuff - admittedly we used a custom memory allocator for the std:: stuff, but it worked fine.

Re: Why is BIND 10 written in C++ and Python?

#114
post #97
post #90

Earlier quoted context omitted.

Obviously I can't speak for these guys, but if I were designing it the fact that Go uses a garbage collector is a pretty strong minus. I like GC'd languages for a lot of tasks, but if I care about performance to the extent that they need to with BIND, I'm not going near it.

Interestingly, they actually wanted a garbage collector: "The language had to address most of the problems with C. Ideally this meant something with good string handling, garbage collection, exceptions, and that was object oriented."

Yeah, I saw that, and my WTF sensor lit up. DNS isn't trivial, but it seems like a sufficiently well-explored problem that memory lifecycles should be pretty well-understood.

Re: Why is BIND 10 written in C++ and Python?

#115
post #111

Earlier quoted context omitted.

>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 ::const_iterator itFace = mesh.getFaces().begin(); for (; itFace != mesh.getFaces().end(); ++itFace) { const Face& face = *itFace; Point faceCentre; std::vector ::const_iterator itVertex = face.vertices.begin(); for (; itVertex != face.vertices().end()…

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(face.vertices().size());
  }

Re: Why is BIND 10 written in C++ and Python?

#116
post #5

Earlier quoted context omitted.

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.

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

Re: Why is BIND 10 written in C++ and Python?

#117

I think it's interesting that they did consider C and then decided it was too much of a risk. There's a constant theme of 'why use C++? C is faster and doesn't suck as much!' especially due to Linus' statements on the language, but often C is a technical risk as there's so much more that can go wrong. I'm not saying C++ is a better language than C, but it's definitely different and given the language is structured to…

>but often C is a technical risk as there's so much more that can go wrong. That is objectively incorrect. There is much less that can go wrong with C, as there is much less period. Everything that you can do incorrectly with C, you can do incorrectly with C++, plus 10 times more things that C++ introduced. The idea that C++ is safer because "we just won't do dangerous stuff" is silly, as any language is safe if you…

> Everything that you can do incorrectly with C, you can do incorrectly with C++

This isn't true. C++ doesn't allow certain implicit casts that C allows (e.g., from void* to T*).

Re: Why is BIND 10 written in C++ and Python?

#118
post #111

Earlier quoted context omitted.

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 ::const_iterator itFace = mesh.getFaces().begin(); for (; itFace != mesh.getFaces().end(); ++itFace) { const Face& face = *itFace; Point faceCentre; std::vector ::const_iterator itVertex = face.vertices.begin(); for (; itVertex != face.vertices().end()…

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

Re: Why is BIND 10 written in C++ and Python?

#120
post #108

Earlier quoted context omitted.

So I used to agree with you, but I've done extensive performance critical C development at Facebook (memcached, a new thing we are about to talk about) and I have also done extensive performance critical c++11 development (our layer 7 load balancer for http) and I'd have to say that c++11 is the far superior option if you really, truly understand what the compiler is doing to your code (a huge caveat). Unique_ptrs ar…

First you are saying c++11 is the far superior option (with that one caveat) and in the last sentence you imply that C would still be faster. Can you clarify? I'll add my opinion too: I think all the readability you can get out of c++, will be wasted in layers upon layers of object oriented design and C compiles much faster, so there is that.

C++11 is the superior option because it is easier to write correct code with it, plain and simple. And we aren't talking about orders of magnitude difference in throughput or latency, we're talking about a slight increase in CPU idle.

And layers upon layers of object oriented crap is also a problem in C (I've seen it). At the end of the day I've just been burned more by the complexities of building large things in C (particularly when people do reference counting in C) than I have been by the complexity of c++ in general.

Post reply on HN