[ODE] ODE .NET Bindings Performance Issues, Unsafe code, etc...

[Gonçalo Lopes]

Dear Daniel,

Rayne's ODE.NET showed just how efficient a MC++ wrapper can be, and
it's probably even easier to develop, since you don't have to go
through the subtleties of P/Invoke and the C# interop to make it
happen. That's why the MC++ is called the IJW (It Just Works)
approach.

Basically, you just have to include the original header files in Ode
and presto, you can use Ode in MC++ (it should really compile right
off the shelf if you link it statically or dynamically with the
ode.dll).

Just some considerations about such a project. First, I believe that
in the IJW approach what really pays off is a direct implementation of
a managed class OOP hierarchy off the Ode functions. It will be more
efficient and more effective than just adding managed methods for the
lower-level calls. There are two main reasons for this:

1. Developing managed methods will just lead you to something like the
C# approach, since you have to perform a 1:1 mapping. This may even be
worse efficiency wise than P/Invoke, since you're not even performing
a direct invocation of the dll functions, but introducing additional
function calls between them.

2. Lower level wrappers is not really what the .NET user wants. That's
just the first step towards exposing a clean object-oriented
functionality, with delegate calls, managed user data, etc... So if
you're already into IJW, why not be more effective and go immediately
to this step?

So basically what I mean is this: if you go into MC++, you can just
bypass the whole lower-level wrapper thing because you already have
it. What could be worthy to share between an efficient MC++ ODE and a
cross-platform fully C# ODE is the high-level class hierarchy, in my
opinion, with the low level methods style being selected in a couple
of macro calls. Either you could compile it with access by P/Invoke or
directly call the Ode methods if in MC++, but the exposed
functionality should be the same.

By the way, I still believe that I can harness close to the same level
of efficiency of MC++ in C# P/Invoke. But you do need to accept that
you will have to include unsafe method calls to avoid triple-copying a
Vector or Matrix each time you set some body parameters. I've done
just that in my recently completed, fully C# ODE P/Invoke wrapper.

I'll be advancing next towards specifying the high-level class
wrapper, which, IF everything went well, could be close to core level
functionality by the end of the week.

But still, maybe I'll think about a MC++ version of the hierarchy as
you suggest. It could indeed be worth it since it's a lot easier to
do.

Best regards,

Gonçalo

On 10/23/06, Daniel Huser <dhuser at 1eeurope.ch> wrote:
>
>
>
> Hi Gonçalo,
>
> >Although I have to admit that being in MC++, ODE.NET was not only
> >faster than Tao.Ode ever was, but it also admitted more bodies on
> >screen, whilst OdeDotNet would blow up with a stack overflow a lot
> >sooner... don't know why though, could just be my example's fault. And
> >this is the main reason why I wanted an efficient and solid low-level
> >binding for the ODE API. I've tried practically all the .NET wrappers
> >ever made for ODE and I'm still not pleased with any of them so I
> >really wanted to make the "official" bindings the definitive solution
> >to this problem.
>
> Well, the .NET wrapper being cross-platform is nice and all, but maybe it
> would be nice to also, additionally, have a high-performance MC++ version of
> it. Do you think it would be a lot of effort to make a low-level wrapper for
> ODE in MC++?
> My c++ and c skills are very limited if one can even call it that. My main
> skills lay in .NET/C#. So i have no idea what it might take to implement
> such a wrapper in MC++, or let's say, what it would take to make ODE compile
> in MC++.
> How much work would it be compared to a C# wrapper? Would it be worth the
> effort to do this side-by-side to a cross-platform .net wrapper?
>
> Regards,
> Daniel
>
>  ________________________________
>  From: Gonçalo Lopes
> Sent: Fri 10/20/2006 0:49
> To: Terry L. Triplett
> Cc: ode at q12.org
> Subject: Re: [ODE] ODE .NET Bindings Performance Issues, Unsafe code, etc...
>
>
> Hello Terry,
>
> I've used OdeDotNet initially and loved the design principles behind
> it. Unfortunately its level of completeness didn't allow me to use it
> at the time. I've switched to ODE.NET but, as I've said, it's dead
> code and not even cross-platform anyway.
>
> However, though, the higher-level part of ODE.NET has some really nice
> design ideas for convenient OOP patterns for such things as collision
> joint groups, callbacks, user data in ODE entities, etc... I liked the
> approach, even though the concrete realization was lacking.
>
> Although I have to admit that being in MC++, ODE.NET was not only
> faster than Tao.Ode ever was, but it also admitted more bodies on
> screen, whilst OdeDotNet would blow up with a stack overflow a lot
> sooner... don't know why though, could just be my example's fault. And
> this is the main reason why I wanted an efficient and solid low-level
> binding for the ODE API. I've tried practically all the .NET wrappers
> ever made for ODE and I'm still not pleased with any of them so I
> really wanted to make the "official" bindings the definitive solution
> to this problem.
>
> Still, my offer of help stands, and I'll definitely take a look at
> what OdeDotNet has become since my last visit, which was somewhere
> near July this year, and I'll get in touch again.
>
> Best regards,
>
> Gonçalo
>
> On 10/19/06, Terry L. Triplett <c0d3g33k at gmail.com> wrote:
> > On 10/19/06, Gonçalo Lopes <goncaloclopes at gmail.com> wrote:
> > > > > * separate the wrapper into two design levels: API bindings level
> > > > > (lower-level wrapper) and .NET level types and classes
> > > >
> > > > I am producing an API binding; I have no plans for a class library but
> > > > welcome anyone else to take up the challenge.
> > >
> > > Ok, I'll be more than happy to help the community on this regard, but
> > > first we need a solid and efficient lower-level API bindings.
> >
> > The 2-design levels approach is the general approach taken by the Tao
> > bindings. The highlevel wrapper corresponding to Tao.Ode (those other
> > 'solid and efficient lower-level API bindings) is OdeDotNet. Since the new
> > Ode bindings will be presenting virtually the same API as Tao, OdeDotNet
> > should be easily adaptable to them, and the project could use some help
> > anyhow.
> >
> >
> >
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>
>