1. Incidentally, if you want to hire me, head over to my business website with my portfolio and contact information.

There are no code changes between the two releases. The only thing that changed is that Fhtagn! moved away from the Boost Software License Version 1.0, and is now licensed under the terms of the GNU General Public License Version 3¹.

If you are a non-commercial user, e.g. if you use this software for personal, educational or other non-profit use, all that changes for you is that you now must publish the source code to any changes you make to this software, provided you distribute these changes in some way.

Commercial users will need to acquire a commercial license if they wish to use 0.3.0 or later. But don’t worry, 0.2.0 will not change it’s license retroactively, and nothing forces you to upgrade. On the other hand, the 0.2.0 branch won’t be developed further (a few bugfixes aside as they come in).

This license change has been long planned. I’ve long been profiting by the great work the Free Software Foundation has been doing. Free software has made my life better. I figured it was high time to give back to the community in earnest.

At this point I’d like to draw your attention to another change in the sources that you might overlook amidst all the changes to license text: the copyright to Fhtagn! now lies with me² rather than “the authors”.

The simple reason for this is that it’s more practical: a single person as the copyright holder means much less hassle when license issues need to be dealt with³. We briefly discussed the alternative of creating some legal non-profit entity and assigning copyright to that, but the other two contributors decided to grant me copyright instead.

And I’d like to take this opportunity to thank them for their invaluable help: the commit history in no way reflects how much support they’ve been during the lifetime of this project.

Without Henning’s contributions and encouragement, this project would not exist. And without Tony’s use of some of Fhtagn!’s features, I probably would have lost interest in the project a long time ago.

Thank you! Comatose Cthulhu is dedicated to you!

1. These changes to not pertain to the scons_util subdirectory of the project, as that contains build files used in other projects of mine.
2. Jens Finkhaeuser
3. Note that for the same reason, future contributions will only be accepted if the contributors also grant copyright to me.

People following this project will note that a number of issues that used to be associated with 0.2.0 got pushed to 0.3.0 in recent weeks. I just felt that I’d rather postpone individual features than keep putting off a release.

Please note that windows is still not officially supported. One of the items on the TODO-list for the next release is to improve on that.

Enjoy!

But given that futures are conceptually like a mixture of read-only properties mixed with a subset of the tasklet-functionality, it was just a no-brainer to write them.

So there you are.

Follow the jump for a quick example on how to use them.

It really couldn’t be simpler: a future is essentially a read-only object of a value type of your choosing, the value of which is calculated in a background thread. When trying to read the value, the code blocks until the background thread has finished:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

using namespace fhtagn::threads;
 
// You need some function to calculate the value with.
// You might want to look into boost::lambda if you want
// to define it inline.
int my_calculating_function();
 
// A future representing an integer type is instanciated
// with the function that calculates is value. This spawns
//  the background thread immediately.
future<int> x(&my_calculating_function);
 
// When reading the value (i.e. using the future in an
// expression), the code blocks until the background
// thread is finished.
int y = 3.1415 * x;
 
// However, once it's calculated, there's no need to run
//  the thread again, and things are much quicker.
int z = x;

Simple, isn’t it? There’s more to it, but not a lot…

This does by no means imply that all the work for making sure Fhtagn! runs on windows is done, though. But it’s a major milestone — and vindicates my assumption that the code is fairly portable!

Enjoy!

Finally, here’s a partial list of things left to do:

• The allocspeed test program doesn’t link yet.
• There are hundreds of compiler warnings, some of which could probably be fixed.
• You can’t build static and dynamic libs — either one at a time works, but not both.

You can find all of that effort in the memory sub-directory in fhtagn!’s trunk — but more important than code, right now, is another question: why should I be interested?

Well, this Python inspired allocator is somewhat clever in that it tries to satisfy the most common allocation requests from pre-allocated pools. It internally manages pools for different object sizes, and considers objects in sizes of two to the power of N: 1, 2, 4, 8, …, 256. Each pool then is little more than an array of entries of this fixed size.

For any allocation request, the allocator will determine which of the 2^N sizes would be large enough to fit the object into, and will take memory from the pool that handles this size — except if the allocation size required is too large, in which case it’ll fall back on the heap.

This allocation scheme works very well for Python. In python, all objects (including integers) are allocated from this allocator individually, which means that this very fast allocation from pre-allocated pools improves performance drastically.

But how does this approach measure up in C++?

To find out, I wrote a little benchmark program for allocators. It tries to imitate very naive usage of STL containers, and therefore uses STL’s vector very simply: it’ll fill a vector with a random amount of entries, then drain a random amount of entries again (from anywhere within the vector, not just the beginning or end), and then repeat the process several times.

The reasoning behind this approach is to simulate a relatively healthy balance between user stupidity and vector’s own approach to allocating smartly: if vector is out of memory, it’ll usually allocate as much memory as it already uses currently — a simple but relatively efficient method for anticipating what the user might do next.

The interesting part about this is that it flies in the face of the size-based pool approach: vector, doubling it’s capacity with each time it runs out of memory, will pretty soon request memory far larger than the size-based pools provide for, thus triggering the fallback solution of allocating from the heap. Once the vector has grown to that stage, there should be no benefit between STL’s default allocator and the size-based pool approach.

In that sense, the tests try to account for the worst case the size-based pools can encounter — but as it’s often impossible to determine the size of a containers before filling it, this usage of vector is also moderately realistic. In balance, I think these tests should paint a pretty realistic picture of the performance of this size-based pool approach¹.

1. Note that the same usage of e.g. STL’s lists or maps would favour the size-based pools approach more

But there was a recent bit of activity on the mailing list that I wanted to share with you, because it was about a constrained value library about to be submitted for review. In the boost world, new libraries are submitted for review, and the results of the review determine whether or not the library is included.

Highly fascinating stuff, if only because Fhtagn! has included pretty much the same functionality for a while now.

So naturally I took a look at the submission, if only to determine whether or not it’s good enough to drop Fhtagn!’s restricted data types in favour of boost’s constrained values. Turns out that I won’t be doing that.

But first, let’s take a brief look at what this sort of code does. I’ll use Fhtagn!’s version, because, well, you’re here already. But note that I’ll use restricted/constrained and restriction/constraint interchangeably in the text below.

The idea is to place constraints on the values that a value type can take. Fhtagn!’s approach was originally inspired by the D language’s approach to design by contract. D allows a function to define a set of constracts, such as the range of values a parameter may take, and throws an exception if that contract is broken.

By associating this sort of contract not with a function, but with a data type, you gain more flexibility, while retaining the ability to define function prototypes with a contract:

1
2
3
4
5
6

// even_int_t is an int that can only ever contain even values.
typedef fhtagn::restricted<int,
  fhtagn::restrictions::numeric::even<int>
> even_int_t;
 
void foo(even_int_t const & param);

The beauty of this is that the even constraint is evaluated before foo()‘s function body is entered.

You’ll note that the restriction we’re using is a template argument to the restricted type. You can even chain restrictions, like this:

1
2
3
4
5
6
7

// positive_even_int_t is an int that can only ever contain positive
// even values.
typedef fhtagn::restricted<int,
  fhtagn::restrictions::numeric::positive<int,
    fhtagn::restrictions::numeric::even<int>
  >
> positive_even_int_t;

Here, it’s first assured that the value to be assigned to the restricted data type is positive, then it’s assured it’s even. If either of the restrictions is violated, an exception is thrown, and nested restrictions are not evaluated any more¹.

And that’s the gist of how restricted data types work. So how do the two implementations differ?

1. It therefore makes sense to first use positive, as that’s very easily evaluated and already excludes half of the search space before even needs to be evaluated. Granted, the latter also excludes half of the search space, but at the cost of an additional division. Yes, I’m being picky here

I’ve also finally removed the mailing lists from sourceforge.net, making this site here the home of all infrastructure for Fhtagn!. The new development mailing list – the only one for now – is fhtagn-devel@unwesen.de. You can find the archives on gmane.org.

The mailing list is handled by ezmlm, which means you subscribe by sending a mail to fhtagn-devel-subscribe@unwesen.de, and get help on further commands by mailing fhtagn-devel-help@unwesen.de.

Enjoy!

Now don’t get me wrong, SCons isn’t the answer to all build problems — but it’s quite a bit better than most build systems out there.

I’d suggest heading over to the SCons User Guide for a bit of background. The README bundled in trunk includes instructions specific to Fhtagn! But if you’re impatient, building Fhtagn! shouldn’t really be a lot more effort than running scons on the command line.

Enjoy!