For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=624>

Summary: Add special case calculations for lower dimensional

vectors - matrices

Product: BFL

Version: trunk

Platform: All

OS/Version: All

Status: NEW

Severity: enhancement

Priority: P3

Component: wrappers

AssignedTo: bfl [..] ...

ReportedBy: tinne [dot] delaet [..] ...

CC: bfl [..] ...

Estimated Hours: 0.0

The wrappers can provide faster special case calculations for lower dimension

vectors and matrices. This would increase speed in a lot of applications.

## [Bug 624] Add special case calculations for lower dimensional ve

For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=624>

--- Comment #3 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2009-02-26 18:06:05 ---

1/ Do you have an idea of the performance gain this brings (for a particular

system, I know. Do we have a KF test that uses 2D matrices somewhere at this

point)

2/ Isn't this something we should try and get in upstream implementations.

After all, BFL wants to provide wrappers and leave matrix functionality in

matrix libraries (Herman, this must sound like good sixties music in your ears

:-)

3/ Since it's committed, you probably could change the status to resolved

(unless you were anticipating annoying remarks from retired phd students, that

is :-)

## [Bug 624] Add special case calculations for lower dimensional ve

On Thursday 26 February 2009 18:06:05 Klaas Gadeyne wrote:

> For more infomation about this bug, visit

> <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=624>

>

>

>

>

> --- Comment #3 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2009-02-26

> 18:06:05 --- 1/ Do you have an idea of the performance gain this brings

> (for a particular system, I know. Do we have a KF test that uses 2D

> matrices somewhere at this point)

So far I don't have an idea about the performance gain....

The test of the filters uses a 3D state. The linear kalman example however uses

a 2d state.

I added a test to the matrixwrapper test (as you can see in the patch), so we

could compare performance directly on the inverse and determinant calls.

> 2/ Isn't this something we should try and get in upstream implementations.

> After all, BFL wants to provide wrappers and leave matrix functionality in

> matrix libraries (Herman, this must sound like good sixties music in your

> ears

>

> :-)

Certainly we do. But, recently I'm not really satisfied with our boost-choice

as a matrix library. Boost is far from real-time and uses allocations in it's

calculations.

I ran some performance checks on our filter examples and from that I learned

that the major part of computation time is spend in doing matrix calculations.

Therefore, me and Herman Bruyninckx are considering switching to eigen2 matrix

library. The only thing we lack is time....

Once switched to eigen2 I would certainly spend time in getting the upstream

implementations as good as possible in stead of incrementally improving our

matrix-wrapper.

> 3/ Since it's committed, you probably could change the status to resolved

> (unless you were anticipating annoying remarks from retired phd students,

> that is :-)

I was expecting remarks, but that was not the reason I didn't change the

status to resolved.

I didn't change it since the title is quit general (see mail subject) and I

only make special case calculation for determinant and inverse in the boost

case. So any other special case calculations can still be implemented (also

for lti and newmat implementations).

Maybe I should reveal underlying reason for this sudden (and unexpected)

change. In an application I'm currently working on, the inverse of a 2x2

matrix (boost) fails due to a failure in the LU-factorization of boost. It's

completely unclear to me why it fails since there is no problem at all with

the matrix.

So a fast solution was to provide a special case implementation of the inverse

;).

Tinne

_______________________________________________

I hereby promise not to top-post on the

BFL mailing list

BFL [..] ...

http://lists.mech.kuleuven.be/mailman/listinfo/bfl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

## [Bug 624] Add special case calculations for lower dimensional ve

[...]

>> 2/ Isn't this something we should try and get in upstream implementations.

>> After all, BFL wants to provide wrappers and leave matrix functionality in

>> matrix libraries (Herman, this must sound like good sixties music in your

>> ears

>>

>> :-)

> Certainly we do. But, recently I'm not really satisfied with our boost-choice

> as a matrix library. Boost is far from real-time and uses allocations in it's

> calculations.

Any idea wether lti/newmat is better (in that respect)?

> I ran some performance checks on our filter examples and from that I learned

> that the major part of computation time is spend in doing matrix calculations.

> Therefore, me and Herman Bruyninckx are considering switching to eigen2 matrix

> library. The only thing we lack is time....

Enter gSoc?

Is KDL using a fixed matrix library (eigen2?)?

>> 3/ Since it's committed, you probably could change the status to resolved

>> (unless you were anticipating annoying remarks from retired phd students,

>> that is :-)

> I was expecting remarks, but that was not the reason I didn't change the

> status to resolved.

> I didn't change it since the title is quit general (see mail subject) and I

> only make special case calculation for determinant and inverse in the boost

> case. So any other special case calculations can still be implemented (also

> for lti and newmat implementations).

Ah, I see. I though that maybe the other libraries realised these

special cases themselves when I saw the patch.

> Maybe I should reveal underlying reason for this sudden (and unexpected)

> change. In an application I'm currently working on, the inverse of a 2x2

> matrix (boost) fails due to a failure in the LU-factorization of boost. It's

> completely unclear to me why it fails since there is no problem at all with

> the matrix.

> So a fast solution was to provide a special case implementation of the inverse

> ;).

Just changing the matrix library was not a (faster) option?

Klaas

_______________________________________________

I hereby promise not to top-post on the

BFL mailing list

BFL [..] ...

http://lists.mech.kuleuven.be/mailman/listinfo/bfl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

## [Bug 624] Add special case calculations for lower dimensional ve

On Friday 27 February 2009 09:42:45 Klaas Gadeyne wrote:

> [...]

>

> >> 2/ Isn't this something we should try and get in upstream

> >> implementations. After all, BFL wants to provide wrappers and leave

> >> matrix functionality in matrix libraries (Herman, this must sound like

> >> good sixties music in your ears

> >>

> >> :-)

> >

> > Certainly we do. But, recently I'm not really satisfied with our

> > boost-choice as a matrix library. Boost is far from real-time and uses

> > allocations in it's calculations.

>

> Any idea wether lti/newmat is better (in that respect)?

For lti no. Newmat needs to be checked.

> > I ran some performance checks on our filter examples and from that I

> > learned that the major part of computation time is spend in doing matrix

> > calculations. Therefore, me and Herman Bruyninckx are considering

> > switching to eigen2 matrix library. The only thing we lack is time....

>

> Enter gSoc?

Yes. We are negotiating this.

> Is KDL using a fixed matrix library (eigen2?)?

Not yet. But Ruben (the developer) is also considering choosing eigen2 as the

matrix library.

We had a quick check and it looks very promising. They give no guarantees to

be allocation free and some are present in the code but we could contribute in

improving this aspect.

> >> 3/ Since it's committed, you probably could change the status to

> >> resolved (unless you were anticipating annoying remarks from retired phd

> >> students, that is :-)

> >

> > I was expecting remarks, but that was not the reason I didn't change the

> > status to resolved.

> > I didn't change it since the title is quit general (see mail subject) and

> > I only make special case calculation for determinant and inverse in the

> > boost case. So any other special case calculations can still be

> > implemented (also for lti and newmat implementations).

>

> Ah, I see. I though that maybe the other libraries realised these

> special cases themselves when I saw the patch.

ok.

> > Maybe I should reveal underlying reason for this sudden (and unexpected)

> > change. In an application I'm currently working on, the inverse of a 2x2

> > matrix (boost) fails due to a failure in the LU-factorization of boost.

> > It's completely unclear to me why it fails since there is no problem at

> > all with the matrix.

> > So a fast solution was to provide a special case implementation of the

> > inverse ;).

>

> Just changing the matrix library was not a (faster) option?

I need some extra functionality from boost in my application so changing the

matrix library was not really an option.

Tinne

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

_______________________________________________

I hereby promise not to top-post on the

BFL mailing list

BFL [..] ...

http://lists.mech.kuleuven.be/mailman/listinfo/bfl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

## [Bug 624] Add special case calculations for lower dimensional ve

On Fri, 27 Feb 2009, Klaas Gadeyne wrote:

> [...]

>>> 2/ Isn't this something we should try and get in upstream implementations.

>>> After all, BFL wants to provide wrappers and leave matrix functionality in

>>> matrix libraries (Herman, this must sound like good sixties music in your

>>> ears

>>>

>>> :-)

>> Certainly we do. But, recently I'm not really satisfied with our boost-choice

>> as a matrix library. Boost is far from real-time and uses allocations in it's

>> calculations.

>

> Any idea wether lti/newmat is better (in that respect)?

A lot of allocations behind the screens...

>> I ran some performance checks on our filter examples and from that I learned

>> that the major part of computation time is spend in doing matrix calculations.

>> Therefore, me and Herman Bruyninckx are considering switching to eigen2 matrix

>> library. The only thing we lack is time....

>

> Enter gSoc?

> Is KDL using a fixed matrix library (eigen2?)?

Ruben (the KDL maintainer) is also looking into Eigen2, and he and me begin

to like it more and more. For me personally, the _major_ reasons to like it

are:

- it can be checked not to use any runtime allocations

- it is now firmly established as _the_ math toolbox for a large scale

project such as KDE

The major reason _not_ to like it is:

- it's only C++ templates, which is not easy.

But the latter problem is traditionally overcome by having only the core

developers being confronted with this complexity, while nothing of it shows

through at the user level APIs... (Except for maybe a "configuration" state

in a state-based template of using BFL code...)

>>> 3/ Since it's committed, you probably could change the status to resolved

>>> (unless you were anticipating annoying remarks from retired phd students,

>>> that is :-)

>> I was expecting remarks, but that was not the reason I didn't change the

>> status to resolved.

>> I didn't change it since the title is quit general (see mail subject) and I

>> only make special case calculation for determinant and inverse in the boost

>> case. So any other special case calculations can still be implemented (also

>> for lti and newmat implementations).

>

> Ah, I see. I though that maybe the other libraries realised these

> special cases themselves when I saw the patch.

>

>> Maybe I should reveal underlying reason for this sudden (and unexpected)

>> change. In an application I'm currently working on, the inverse of a 2x2

>> matrix (boost) fails due to a failure in the LU-factorization of boost. It's

>> completely unclear to me why it fails since there is no problem at all with

>> the matrix.

>> So a fast solution was to provide a special case implementation of the inverse

>> ;).

>

> Just changing the matrix library was not a (faster) option?

>

> Klaas

Herman

_______________________________________________

I hereby promise not to top-post on the

BFL mailing list

BFL [..] ...

http://lists.mech.kuleuven.be/mailman/listinfo/bfl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

## [Bug 624] Add special case calculations for lower dimensional ve

On Feb 27, 2009, at 03:49 , Herman Bruyninckx wrote:

> On Fri, 27 Feb 2009, Klaas Gadeyne wrote:

>

>> [...]

>>>> 2/ Isn't this something we should try and get in upstream

>>>> implementations.

>>>> After all, BFL wants to provide wrappers and leave matrix

>>>> functionality in

>>>> matrix libraries (Herman, this must sound like good sixties music

>>>> in your

>>>> ears

>>>>

>>>> :-)

>>> Certainly we do. But, recently I'm not really satisfied with our

>>> boost-choice

>>> as a matrix library. Boost is far from real-time and uses

>>> allocations in it's

>>> calculations.

>>

>> Any idea wether lti/newmat is better (in that respect)?

>

> A lot of allocations behind the screens...

Like you wouldn't believe for newmat/roboop! IIRS every single

variable (eg matrix, vector) is dynamically allocated. We had a 10x

speedup going from Roboop to KDL for 6DOF forward/inverse kinematics.

S

_______________________________________________

I hereby promise not to top-post on the

BFL mailing list

BFL [..] ...

http://lists.mech.kuleuven.be/mailman/listinfo/bfl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

## [Bug 624] Add special case calculations for lower dimensional ve

For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=624>

--- Comment #2 from Tinne De Laet <tinne [dot] delaet [..] ...> 2009-02-26 12:53:28 ---

Patch (attachment #390) applied in revision 30007:

svn commit

Sending src/wrappers/matrix/matrix_BOOST.cpp

Sending tests/matrixwrapper_test.cpp

Transmitting file data ..

Committed revision 30007.

## [Bug 624] Add special case calculations for lower dimensional ve

For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=624>

--- Comment #1 from Tinne De Laet <tinne [dot] delaet [..] ...> 2009-02-26 12:51:38 ---

Created an attachment (id=390)

--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=390)

Adds special case calculation for determinant and inverse for 1 and 2

dimensional boost matrices