The dlib C++ library
lot of useful things for Orocos, such as a portable threading API,
templated matrix/vector operations that are realtime safe (they say) and
that offer SVD, graphs and Bayesian networks including a junction tree
algorithm, ...
So, has any of you already taken a much closer look at this project?
And found reasons (not) to contact these people for a possible closer
cooperation...?
Herman
Experience with dlib C++....?
On Sun, 7 Sep 2008, Robert Schwebel wrote:
> On Sun, Sep 07, 2008 at 05:30:07PM +0200, Herman Bruyninckx wrote:
>> The dlib C++ library
>> lot of useful things for Orocos, such as a portable threading API,
>> templated matrix/vector operations that are realtime safe (they say) and
>> that offer SVD, graphs and Bayesian networks including a junction tree
>> algorithm, ...
>>
>> So, has any of you already taken a much closer look at this project?
>> And found reasons (not) to contact these people for a possible closer
>> cooperation...?
>
> Wouldn't it be more "standard" to go the Boost way if you want to do
> threading, matrix/vector etc in C++?
>
As far as I understand, this is an extension of the standard Boost
developments. (But I can be mistaken!)
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Experience with dlib C++....?
On Sunday 07 September 2008 20:31:22 Robert Schwebel wrote:
> On Sun, Sep 07, 2008 at 05:30:07PM +0200, Herman Bruyninckx wrote:
> > The dlib C++ library
> > lot of useful things for Orocos, such as a portable threading API,
> > templated matrix/vector operations that are realtime safe (they say) and
> > that offer SVD, graphs and Bayesian networks including a junction tree
> > algorithm, ...
> >
> > So, has any of you already taken a much closer look at this project?
> > And found reasons (not) to contact these people for a possible closer
> > cooperation...?
>
> Wouldn't it be more "standard" to go the Boost way if you want to do
> threading, matrix/vector etc in C++?
I agree. There is much overlap with Boost and even the *current* C++ standard.
I have much respect for his work, it looks clean and covers a broad spectrum
of the tools you need in day-to-day C++ programming. However, I'd like to see
the claim and code that says it's usable in real-time, or even thread-safe
contexts.
Peter
Experience with dlib C++....?
On Mon, 8 Sep 2008, Peter Soetens wrote:
> On Sunday 07 September 2008 20:31:22 Robert Schwebel wrote:
>> On Sun, Sep 07, 2008 at 05:30:07PM +0200, Herman Bruyninckx wrote:
>>> The dlib C++ library
>>> lot of useful things for Orocos, such as a portable threading API,
>>> templated matrix/vector operations that are realtime safe (they say) and
>>> that offer SVD, graphs and Bayesian networks including a junction tree
>>> algorithm, ...
>>>
>>> So, has any of you already taken a much closer look at this project?
>>> And found reasons (not) to contact these people for a possible closer
>>> cooperation...?
>>
>> Wouldn't it be more "standard" to go the Boost way if you want to do
>> threading, matrix/vector etc in C++?
>
> I agree. There is much overlap with Boost and even the *current* C++ standard.
>
> I have much respect for his work, it looks clean and covers a broad spectrum
> of the tools you need in day-to-day C++ programming. However, I'd like to see
> the claim and code that says it's usable in real-time, or even thread-safe
> contexts.
>
They claim the realtime behaviour via the use of "expression templates":
Herman
RE: Experience with dlib C++....?
> >
> > I have much respect for his work, it looks clean and covers a broad
> spectrum
> > of the tools you need in day-to-day C++ programming. However, I'd
like
> to see
> > the claim and code that says it's usable in real-time, or even
thread-
> safe
> > contexts.
> >
> They claim the realtime behaviour via the use of "expression
templates":
>
>
> Herman
Hey,
Using template meta programming doesn't automatically make your software
realtime. There is no question it will make it faster, though.
This library is just about efficient C++ programming, not about
realtime.
The expression M = A+B+C+D; for example can also be written as:
M += A; M += B; M += C; M += D;
No temporary object either!
Let's not forget (our) the meaning of realtime:
It is not "as fast as possible", witch could be applied to the stock
market.
It is more like "always deterministic behavior", and this takes more
than efficient C++ programming.
To cut this short: I agree with Peter.
Sander.
RE: Experience with dlib C++....?
Out of curiosity, what exactly do you guys think of when you talk of realtime? Certainly most people mean some sort of "always deterministic behavior." However, when I talk to people I get responses ranging from, just having control over memory allocation, to having some spreadsheet that documents the maximum number of clock cycles every function might take depending on its inputs.
-Davis
RE: Experience with dlib C++....?
On Friday 03 October 2008 21:50:13 davis685 [..] ... wrote:
> Out of curiosity, what exactly do you guys think of when you talk of
> realtime? Certainly most people mean some sort of "always deterministic
> behavior." However, when I talk to people I get responses ranging from,
> just having control over memory allocation, to having some spreadsheet that
> documents the maximum number of clock cycles every function might take
> depending on its inputs.
We're talking a deterministic response time to an event. In practice, we
enforce this by choosing a real-time scheduler and to not put any memory
allocations in our critical path.
This 'no-malloc' has severe restrictions and forces us to pre-allocate memory
(for the worst case), which isn't memory efficient. Other projects solve this
by using a 'real-time memory allocator' (xenomai, RTAI,...) or let the user
specify it (the C++ std library allows this for example).
I have become a fan of the real-time malloc approach, especially since this
implementation exists [1] because it performs decently (fast and
deterministic) and is widely accepted. I just didn't have the time yet to
prepare a patch to get it into RTT.
Peter
[1] http://rtportal.upv.es/rtmalloc/
RE: Experience with dlib C++....?
[
On Friday 03 October 2008 21:50:13 davis685 [..] ... wrote:
> Out of curiosity, what exactly do you guys think of when you talk of
> realtime? Certainly most people mean some sort of "always deterministic
> behavior." However, when I talk to people I get responses ranging from,
> just having control over memory allocation, to having some spreadsheet that
> documents the maximum number of clock cycles every function might take
> depending on its inputs.
We're talking a deterministic response time to an event. In practice, we
enforce this by choosing a real-time scheduler and to not put any memory
allocations in our critical path.
This 'no-malloc' has severe restrictions and forces us to pre-allocate memory
(for the worst case), which isn't memory efficient. Other projects solve this
by using a 'real-time memory allocator' (xenomai, RTAI,...) or let the user
specify it (the C++ std library allows this for example).
I have become a fan of the real-time malloc approach, especially since this
implementation exists [1] because it performs decently (fast and
deterministic) and is widely accepted. I just didn't have the time yet to
prepare a patch to get it into RTT.
Yeah, I feel the same way. In dlib I took the same approach to this as the standard library (although dlib does come with a few non-default allocators like a free list implementation but it is not nearly as sophisticated as the TLSF allocator).
Anyway, if any of you are using dlib and finding that some parts of it are annoyingly non-realtime when there isn't any good reason for it then I would be very intereted in hearing about that. E.g. I don't expect the GUI stuff to be realtime but I do expect the threads, pipes, matrix, and other things like that to be useable in a realtime system.
-Davis
RE: Experience with dlib C++....?
On Mon, 8 Sep 2008, Vandenbroucke Sander wrote:
>>> I have much respect for his work, it looks clean and covers a broad
>> spectrum
>>> of the tools you need in day-to-day C++ programming. However, I'd
> like
>> to see
>>> the claim and code that says it's usable in real-time, or even
> thread-
>> safe
>>> contexts.
>>>
>> They claim the realtime behaviour via the use of "expression
> templates":
>>
>>
> Using template meta programming doesn't automatically make your software
> realtime. There is no question it will make it faster, though.
>
> This library is just about efficient C++ programming, not about
> realtime.
As long as you guarantee to avoid memory allocation, you are serving
realtime very well :-)
> The expression M = A+B+C+D; for example can also be written as:
> M += A; M += B; M += C; M += D;
> No temporary object either!
>
> Let's not forget (our) the meaning of realtime:
> It is not "as fast as possible", witch could be applied to the stock
> market.
> It is more like "always deterministic behavior", and this takes more
> than efficient C++ programming.
I agree!
And personally I would still advocate using the old, proven FORTRAN
libraries for all numerical things, but apparently, most "modern"
programmers only want to see C++ or Java... :-(
Herman