April 7, 2014, 10:02 a.m.

    Bitcoin RPC from Python

      The reference bitcoin client includes a powerful API and RPC interface.

      In this post I show you how to call into this from Python (which is something that turns out to be almost trivially easy to set up).

      Python can work well as a kind of (overpowered) scripting language for automating complicated tasks through the bitcoin reference client, but this is also a great way to get started out if you're interested in writing more involved software that works with bitcoin transactions or the bitcoin blockchain.

      Comments (view full post)

    Jan. 21, 2014, 4:55 p.m.

    Custom Vector Allocation

      (Number 6 in a series of posts about Vectors and Vector based containers.)

      A few posts back I talked about the idea of 'rolling your own' STL-style vector class, based my experiences with this at PathEngine.

      In that original post and these two follow-ups I talked about the general approach and also some specific performance tweaks that actually helped in practice for our vector use cases.

      I haven't talked about custom memory allocation yet, however. This is something that's been cited in a number of places as a key reason for switching away from std::vector so I'll come back now and look at the approach we took for this (which is pretty simple, but nonstandard, and also pre C++11), and assess some of the implications of using this kind of non-standard approach.

      I approach this from the point of view of a custom vector implementation, but I'll be talking about some issues with memory customisation that also apply more generally.

      Comments (view full post)

    Dec. 22, 2013, 4:41 p.m.

    Zero Initialisation for Classes

      (Number 5 in a series of posts about Vectors and Vector based containers.)

      This is a response to comments on a previous post, roll your own vector, and has also been rewritten and updated fairly significantly since first posted.

      In roll your own vector I talked about a change we made to the initialisation semantics for PathEngine's custom vector class. In my first followup post I looked more closely at possibilities for replacing resize() with reserve() (which can avoid the initialisation issue in many cases), but so far I'm been concentrating pretty much exclusively on zero initialisation for built-in types. In this post I come back to look at the issue of initialisation semantics for class element types.

      Comments (view full post)

    Dec. 20, 2013, 4:39 p.m.

    Avoid resize()?

      (Number 4 in a series of posts about Vectors and Vector based containers.)

      This post is essentially a response to feedback to this previous post.

      In that post I talked about a change we made to the initialisation semantics for PathEngine's custom vector class, and described a specific use case where this can make a difference, with that use case involving calls to the vector resize() method.

      In the comments for that post, Herb Sutter says:

      Thomas, I think the point is that "reserve + push_back/emplace_back" is the recommended style and the one people do use. Really resize() is not used often in the code I've seen; you use resize() only when you want that many extra default-constructed elements, since that's what it's for.

      In this post I'll be looking into our use case in a bit more detail, and in particular whether or not a resize() call is actually required.

      Comments (view full post)

    Dec. 15, 2013, 12:14 p.m.

    Roll-Your-Own Vector

      (Third in a series of posts about Vectors and Vector based containers.)

      STL vectors offer a great combination of dynamically resizing convenience and low level contiguous buffer accessing performance, but std::vector is not the only option, and custom implementations of this container can sometimes be a better fit for your specific requirements.

      Comments (view full post)

    Nov. 22, 2013, 12:45 p.m.

    Efficient Vectors of Vectors

      (Second in a series of posts about Vectors and Vector based containers.)

      STL style vectors are convenient because they hide the details of internal buffer management, and present a simplified interface, but sometimes convenience can be a trap!

      In my previous post I touched briefly on STL vectors with non-simple element types, and mentioned the 'vector of vectors' construct in particular as a specific source of memory woes.

      In this post I'll talk about this construct in more detail, explain a bit about why there is an issue, and go on to suggest a fairly straightforward alternative for many situations.

      Comments (view full post)

    Nov. 18, 2013, 10:39 a.m.

    Using STL Vectors

      (First in a series of posts about Vectors and Vector based containers.)

      STL style vectors are a pretty useful construct.

      I remember coming to C++ (and the STL) from a background in lower level programming, and finding STL vectors a bit surprising, with the idea of amortized constant time complexity and so on.

      And then it was actually something of a minor revolution just to be able to set up a contiguous data buffer, without any significant programming effort, and without knowing the maximum required buffer size in advance.

      Before we had C++ and the STL I remember a common source of errors being dynamically generated data overflowing fixed buffers, which is something we just don't see any more, thanks in no small part to the humble vector (and brethren).

      But convenience can come at a cost, and there's some stuff you need to be careful about when applying STL vectors in performance critical situations.

      In this post I'll discuss the main ways in which STL style vectors are applied in PathEngine, and look at some of the key performance and memory points coming out of this.

      Comments (view full post)