Here are the Reference documents for each of the language bindings provided by BRAHMS. There follows a quick run-down of the status of each binding. But the general rule, as always, is stick with what you know. Naturally, you can't get faster than a native Process, and the usual rules apply about what will run fast in what language: in particular, interpreted languages may execute considerably slower for certain types of Process.

Each binding is referred to by its number, pronounced in hundreds - that is, "Twelve sixty-six", "Eleven ninety-nine", etc. The reason for this will become clearer as we accrue further bindings in the same languages.

  • The bindings that are not currently thread-safe (1258 and 1262) can still multi-process, using Concerto, so Processes can approach the same speed-up as they would get from multi-threading by using multi-processing.


Components developed against this binding (1266) compile to native BRAHMS modules, and run without overhead. This binding is stable. But we strongly recommend you use a C++ binding, even if you're a C developer, because they're really much easier to use - you can still author your component in C, more or less, but you will find the interface much less effort to use from C++.

Pros and Cons

The onus on the user of the C binding is two-fold. First, the binding does not handle the four module-level Events. Second, wrappers for calls on Data and Utility objects are not available, so they must be made the long way round: creating an Event, initialising it, and firing it. On the plus side, you can't BRAHMS faster than this (but a good optimising compiler will probably make as good a binary from code written against a C++ binding).

Future directions

A future C binding will likely handle the module-level events.


  • 1065 is a legacy binding - developers of new C++ components should use 1199 (quite similar, more efficient).

The C++ binding (1199) is stable, efficient, and the choice of champions, provided you can write C, at least. This binding is used for all Standard Library components (as and when they are upgraded from 1065, anyway).

Pros and Cons

The C++ binding is high performance, whilst offering the interface in perhaps its most intuitive form. No real downside to this one.

Future directions

No current plans.


1258 is stable, has undergone significant testing, and is fully functional.

Pros and Cons

The Matlab binding has the advantage of rapid adoption for the Matlab user. However, it is implemented using the Matlab Engine, which raises the following concerns.

  • The engine is thread-sensitive, and cannot be held open after execution, so it must be started anew on each BRAHMS run, causing typically a two to three second delay on each execution. Discussion with Mathworks continues.
  • The engine is not thread-safe, so BRAHMS processes written in Matlab cannot be run concurrently in the same memory-space (though they can be distributed using Concerto, as noted above).
  • BRAHMS and Matlab interacting in this way do not play all that nice, so calling the framework during event processing is a little ugly (though, fully functional).

Future directions

We expect to review and update this binding when time permits, with a view to addressing the issues raised above. In particular, we may move to a model where the Matlab code is compiled, rather than interpreted at run-time, and we would hope to resolve the imperfections of the framework calling convention as well, through this approach.

In addition, there is a possibility that 1258 itself could be replaced in a backwards-compatible way, speeding the execution of processes authored against it. No promises there, though.


This binding (1262) has now undergone a fair amount of testing, and should be fairly stable.

Pros and Cons

1262 is closely based on 1258 (port by Tak-Shing Chan), with much slicker framework calls, and no thread-sensitivity issues. We are, mostly, very pleased with this binding. However, the Python binding is also not currently thread-safe, restricting parallelisation to Concerto rather than Solo.

Future directions

1) We hope that in the future, support from the Python developers will allow us to relieve the thread-safety restriction, without the need to modify any user-developed Components.

2) We expect to develop a new Python binding that takes the form of a class (rather than a function, which was inherited from the Matlab binding), making the interface more intuitive.