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

[Gonçalo Lopes]

Thanks for your feedback. I understand your predicament quite well,
since I've been out of one just like that in the last week :-) hang on
there!

I'll just post some quick replies to the community or yourself to comment upon:


> > Rayne's bindings used Managed C++ to directly access the C-API and
>
> MC++ doesn't work on Mono on non-Windows platforms.
>

This was just an introductory statement, I'm also all up for Mono and
non-Windows platforms. I believe on a 100% C# approach.

> >   * 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.

> >   * 'unsafe' code should be allowed in the lower-level wrapper to
> > account for efficiency and 1:1 mapping (unsafe is not really unsafe...
>
> If there is a compelling reason to use unsafe code, I'll use it. So
> far there hasn't been. I'm happy to discuss a specific API call.

There are lots of examples, but I'll just post a simple code snippet
here (note that some functions involving this example have still not
been wrapped, so I'm just imagining here):

foreach(IntPtr b in myListBodies) {
   Mass m
   // In the next call we have:
   //  - marshalling array, dReal and matrix here inside unmanaged space
   //  - filling up of the array, dReal and matrix in ODE unmanaged space
   //  - marshalling out the filled up structure
   d.BodyGetMass(ref mass);
   {
        // some mass readonly tests
   }
}

This seems to me strikingly inefficient for something that in plain C
you just pass a pointer around. 2 marshalls (one to go inside the
unmanaged space and another to return) of a sufficiently large
structure to be significant in large body loops, even if they only
care about reading the structure.

>
> >   * prepare and approach a standardization of the unmanaged side ODE
> > C-API following object oriented patterns
>
> I'm not touching this one.

I'm sorry about that, but it's not vital. It would just make the job easier.

> > Keep up the good work,
>
> Thanks! Like I said, I hope to get back to it very soon. (did you ever
> have one of those tasks that seemed so easy, but then just seems to
> get deeper and deeper...and deeper? Yeah, that's me right now)
>

I would be glad to keep up these questions and even help with
development if you're all out of time. In fact, I had started my own
wrapper from scratch using unsafe code when I heard about the official
bindings.

As of now I have completely wrapped the "objects.h" file function
calls and began some high-level API specification for C# OOP but I
stopped in some major design decisions I couldn't decide upon. Now
with these bindings I had hoped to settle the matter complete.

I remain open for discussions and I maintain that all my arguments
have held up so far.

Good luck with all your work :-),

Gonçalo

On 10/19/06, Jason Perkins <starkos at gmail.com> wrote:
> On 10/19/06, Gonçalo Lopes <goncaloclopes at gmail.com> wrote:
> > I've been using the James Rayne's ODE.NET bindings for quite some time
> > and I was pretty excited to hear that some official bindings were
> > surging up in the main ODE development branch.
>
> I'm the one who started that - but I am totally swamped right now
> (again, sorry) and haven't been able to flesh it out. I will try to
> answer your questions quickly. I hope to put some more work into it
> after the EOM.
>
>
> > Rayne's bindings used Managed C++ to directly access the C-API and
>
> MC++ doesn't work on Mono on non-Windows platforms.
>
>
> >   * 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.
>
>
> >   * 'unsafe' code should be allowed in the lower-level wrapper to
> > account for efficiency and 1:1 mapping (unsafe is not really unsafe...
>
> If there is a compelling reason to use unsafe code, I'll use it. So
> far there hasn't been. I'm happy to discuss a specific API call.
>
>
> >   * prepare and approach a standardization of the unmanaged side ODE
> > C-API following object oriented patterns
>
> I'm not touching this one.
>
>
> > Keep up the good work,
>
> Thanks! Like I said, I hope to get back to it very soon. (did you ever
> have one of those tasks that seemed so easy, but then just seems to
> get deeper and deeper...and deeper? Yeah, that's me right now)
>
> Jason
>