![]() ![]() BRAHMS
Reference Manual » Component Interface » Bindings
This documentation is offline - click here to go online
Index | Search: Go online to use Search
| ||
OverviewHere 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. Notes
CComponents 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 ConsThe 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 Future directionsA future C binding will likely handle the module-level events. C++Notes
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 ConsThe C++ binding is high performance, whilst offering the interface in perhaps its most intuitive form. No real downside to this one. Future directionsNo current plans. Matlab1258 is stable, has undergone significant testing, and is fully functional. Pros and ConsThe 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.
Future directionsWe 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. PythonThis binding (1262) has now undergone a fair amount of testing, and should be fairly stable. Pros and Cons1262 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 directions1) 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. |
||
This is a documentation page for the BRAHMS Modular Execution (Simulation) Framework. For details of licensing and distribution, please click here. To advise of an error or omission, please click here. |