This project has moved and is read-only. For the latest updates, please go here.

Public Native Interface

Jul 29, 2009 at 2:29 PM

Hi,

I checked in an updated version of the public native interface - http://github.com/cuda/mathnet-numerics/tree/public_native

I sorta merged the native1 and native2 approaches.  This approach would have separate interfaces for LinearAlgebra, RandomNumbers, FFT, SpecialFunctions, etc. Users can set the default execution mode (native or managed) using the Control class. If somebody wanted to to mix and match native and managed modes, they would use AlgorithmFactory - most users wouldn't touch this factory.  At the moment, I just have the BLAS type methods for ILinearAlgebra outlined - but the rest would follow the same outline.  There is no point in flushing out all the interfaces until we agree an overall approach.

Please comment.

Regards,

Marcus

Jul 29, 2009 at 6:55 PM

Hi Marcus,

Thanks for the work, looking good. Some feedback:

  • How does this approach separate between 32bit and 64bit native (and between different libs)? Simply by renaming the right one to MathNet.Numerics.Native.dll, as mentioned in the other discussion?
  • I like that there's only one project (and one resulting binary) for the library and the test each, makes everything easier.
  • Strategy/Factory pattern makes sense. Should we also provide a way to allow a user to inject a custom strategy/implementation? Should we cache the (default) strategies?
  • I like the speaking names and the convenience methods in the ILinearAlgebra interface.
  • I never liked flags like the Transpose and Norm enums much, but without them we would have quite a method explosion, so please keep them, good compromise.
  • Not sure about the namespaces. I'm aware that the implementations are internal, but the interface is still a low-level way of working with the library. Should we put everything into Algorithms subnamespaces? Would we still want to separate between native and managed namespaces then, or would the class prefixes suffice? Or put the interface into the Algorithms namespaces and keep the implementations in those "device"-specific namespaces?
  • Instead of the interfaces we could also use the managed case as base class and override the methods in the native case (or cases). I don't remember, did we already discuss this somewhere and ruled it out for some reason?

Thanks,
Chris

Jul 29, 2009 at 7:22 PM

Hi Chris,

>How does this approach separate between 32bit and 64bit native (and between different libs)? Simply by renaming the right one to MathNet.Numerics.Native.dll, as mentioned in the other discussion?
Yep, but the build scripts would always name the native DLL MathNet.Numerics.Native.dll. We'd just place them in different directories -MKL\32bit, MKL\64bit, ACML\32bit, ACML\64bit, etc.

>I like that there's only one project (and one resulting binary) for the library and the test each, makes everything easier.
There could still be three resulting libraries - MathNet.Numerics.dll but one for each of the three different platforms. I'd like to only provide an AnyCpu build (see the other discussion).

>Should we put everything into Algorithms subnamespaces?
Sure.

>Would we still want to separate between native and managed namespaces then,
Right, we don't need the seperate namespaces. I'll move the classes into the Algorithms.LinearAlgebra

>Or put the interface into the Algorithms namespaces and keep the implementations in those "device"-specific namespaces?
I'd avoid having device specific code (by device I'm referring to MKL, ACML, CUDA, EIGEN, ATLAS, etc).  It leads a lot of code duplication. The nice thing though is you can have nicely named native libraries. MathNet.Numerics.MKL.dll, MathNet.Numerics.ACML.dll, etc.

>Instead of the interfaces we could also use the managed case as base class and override the methods in the native case (or cases). I don't remember, did we already discuss this somewhere and ruled it out for some reason?
I need to think that through.

Regards,

Marcus

 

 

Jul 29, 2009 at 11:01 PM

Hi Marcus,

I'm kind of merging the two threads here.

Just to be sure I understand how this would work:

On x86:
MathNet.Numerics.dll (AnyCpu) (managed only case)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (MKL\32bit)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (ACML\32bit)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (...\32bit)

On x64:
MathNet.Numerics.dll (AnyCpu) (managed only case)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (MKL\64bit)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (ACML\64bit)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (...\64bit)

On x64 with Wow64 (maybe, with some tricks):
MathNet.Numerics.dll (AnyCpu) (managed only case)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (MKL\32bit)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (ACML\32bit)
MathNet.Numerics.dll (AnyCpu) + MathNet.Numerics.Native.dll (...\32bit)

So we would only have one managed AnyCpu version and build, but various native libraries that are chosen at configuration time, by simply copying the right directory to bin. That will work, with no type/pointer size issues?

I'd be fine with that. That would also mean that the interfaces make more sense than class inheritance, since in managed code there's only one native class per interface anyway.

I just fetched the new version (b8782e3e), looking good. I agree, let's not wait too long to apply.

Thanks,
Chris

Jul 30, 2009 at 6:50 AM

Hi Chris,

>So we would only have one managed AnyCpu version and build, but various native libraries that are chosen at configuration time, by simply copying the >right directory to bin. That will work, with no type/pointer size issues?

That has been my experience.  When using AnyCpu the runtime you use determines the type/pointer size (the 32bit runtime uses 32bit pointers, the 64bit runtime uses 64bit pointers, and the 64bit runtime with assemblies tagged with corflag /32bit+ uses 32bit pointers).  I'll verify this with dnA this later today.

Thanks,
Marcus

Jul 30, 2009 at 12:26 PM

Using AnyCpu worked as expected with the native build of dnAnalytics.

on 32bit Windows with 32bit native library - success
on 32bit Windows with 64bit native library - fail

on 64bit Windows with 32bit native library - fail
on 64bit Windows with 32bit native library using corflags /32bit+ - success
on 64bit Windows with 64bit native library - success

 

 

Aug 4, 2009 at 5:29 PM

Hi Marcus,

If we agree (any other voices?) on merging

Managed.csproj + Native.csproj -> Numerics.csproj
Managed.UnitTests.csproj + Native.UnitTests.csproj -> UnitTests.csproj

as suggested by your changes, can we apply them (only bc4404cf and b8782e3e, but not b7dc31dcf)? I currently hold my changes back in order to keep your commits applicable in the fork queue. We can still discuss about the native interface design, namespaces, factory etc. once it's there.

Or as an alternative, we (or I) could split the two changes (merging/renaming projects and native interface infrastructure) into separate commits and for now only apply the former?

Thanks,
Chris

Aug 4, 2009 at 7:28 PM
Edited Aug 4, 2009 at 7:29 PM

Hi Chris,

The branch is really for discussion purposes, so there is no need to
hold back on any commits. It would be pretty easy to make these
changes (if we do merge the managed and native projects) directly in
main branch (as apposed to merging/apply this branch).

As for merging the managed and native projects, I'm in favor of it if
we expose the algorithm interfaces to the public (ILinearAlgebra, etc
with managed and native implementations). I think we should so other
projects can use them.

Regards,
Marcus

Aug 4, 2009 at 7:44 PM

Hi Marcus,

ok

Yes, I'd vote to keep these kind-of core algorithm implementation abstraction interfaces public as well, together with the factory (but not the actual implementations).

Thanks,
Chris

Aug 11, 2009 at 7:12 PM

Hi,

I'm going to start working on the matrix and vector classes tomorrow and will make this change*. But I'm only work on the managed implementation until we come to agreement on how to handle the native implementation.  Should I hold off on applying this change until everyone commits what they are currently working on?

Thanks,
Marcus

* Dropping the Native and Native.UnitTests projects
* Renaming the Managed project to Numerics
* Renaming the Managed.UnitTests project to UnitTests
* Add the ILinearAlgebra interface and AlgorithmFactory class  

 

Aug 12, 2009 at 5:00 PM

Yep; the change is cool with me. Will wait for Chris's experiments on the runtime checking of native implementation before commenting on that.

Aug 12, 2009 at 6:43 PM
Edited Aug 12, 2009 at 9:41 PM

Sorry, I got lost - Jurgen, what experiments did you have in mind? Or did you mean marcus' experiment in the 6th post of this thread?

Thanks
Chris

Aug 12, 2009 at 10:42 PM

I meant the things on the bottom of this thread.

J