Task Parallel Library

Jul 29, 2009 at 8:10 AM

Hey Guys,

How do we want to handle threading in the new library?  Our goal should be to use parallel code wherever possible.

It looks like MS isn't going to back port the Task Parallel Library to .NET 2. For dnA, we created our own threading pool (gave us more control over the number threads than the System pool) and a partial clone of the TPL Parallel class.  However, I just noticed that there was a Mono Summer of Code project that created the TPL for Mono.  In a discussion on Mono's dev-list, it looks like it is going to be added to Mono's trunk this week.  I'm wondering if we should use their TPL implementation instead of the dnA clone.  We'd basically take the Mono TPL code (licensed under X11) and add it to our project.  Then we'd use preprocessor directives to use the Mono TPL if are doing a .NET 2.0 build or use the MS TPL for .NET 4.0 builds.

Any opinions?

Thanks,

Marcus

Coordinator
Jul 29, 2009 at 9:29 AM

Hi Marcus,

I've ported the dnA implementation over to Math.NET Numerics yesterday, although with some threading modifications.

Yes, let's compare it to what will be added to Mono once it's available, and replace or merge it if it the Mono implementation looks better.

Thanks,
Chris

Jul 29, 2009 at 9:44 AM

Hi Chris,

Nice improvements to the ThreadQueue! I'll port them back to dnA.

Thanks,

Marcus

Coordinator
Jul 29, 2009 at 11:19 AM

Yes, waiting for Mono and comparing sounds like a good plan. I'm wondering what our release set will look like then:

Math.NET Numerics for .NET 2.0
Math.NET Numerics for .NET 4.0

Math.NET Numerics 32 bit
Math.NET Numerics 64 bit

Math.NET Numerics with managed backend
Math.NET Numerics with native backend

(Almost?) all combinations thereof?

Jul 29, 2009 at 11:30 AM
Edited Jul 29, 2009 at 11:32 AM

We need to have:
Math.NET Numerics Managed
Math.NET Numerics Native 32 bit
Math.NET Numerics Native 64 bit

The 32bit and 64bit versions are need so that the runtime uses the
correct pointer sizes for the native libraries.

If we use TPL, then we have to have:
Math.NET Managed for .NET 2.0
Math.NET Numerics Native 32 bit for .NET 2.0
Math.NET Numerics Native 64 bit for .NET 2.0

Math.NET Managed for .NET 4.0
Math.NET Numerics Native 32 bit for .NET 4.0
Math.NET Numerics Native 64 bit for .NET 4.0

Using our own threading classes removes the needed for the .NET 4.0 builds.


If we expose the native interface, that throws in another monkey
wrench - since I was proposing that we combine the managed and native
projects. In that case we'd have:
Math.NET Numerics AnyCpu
Math.NET Numerics 32 bit
Math.NET Numerics 64 bit

If we use TPL, then we have to have:
Math.NET AnyCpu for .NET 2.0
Math.NET Numerics 32 bit for .NET 2.0
Math.NET Numerics 64 bit for .NET 2.0

Math.NET AnyCpu for .NET 4.0
Math.NET Numerics 32 bit for .NET 4.0
Math.NET Numerics 64 bit for .NET 4.0


Regards,
Marcus

Jul 29, 2009 at 6:57 PM

What if we only offered an AnyCpu build of the library? If a user wanted to use the native libraries, it would be up to him to use the correct native library (32bit or 64bit) for his platform.  The only drawback I can think of is that if someone wanted to use a 32bit version of the native libraries on a 64bit machine - they'd have to use corflag to force the app into 32bit mode (is there another option?).

If this acceptable, then might want to merge the managed and native projects now - before we get too far along.

What does everyone think?