[Mono-dev] Integrating Mono.Simd into Mono.Math, Mono.Security

Sebastien Pouliot sebastien.pouliot at gmail.com
Mon Jun 8 14:47:23 EDT 2009

Hello Marcus,

On Mon, 2009-06-08 at 13:45 -0400, Marcus Griep wrote:
> Hello all,
> First, by way of introduction, I'm Marcus Griep, a .NET/Mono
> developer for some time now, and a contributor to such projects as
> Boo, C5, and git.
> In a sort of scratch-my-own-itch style, I'm looking to speed up the
> computationally time consuming steps of BigInteger math by using
> Mono.Simd in Mono.Math. This would then vicariously speed up various
> cryptographic functions that rely on BigIntegers, such as primality
> tests in RSA, and could be futher extended to using Mono.Simd
> throughout Mono.Security.

BigInteger is used for RSA, DSA and DH (the later not being part of
mscorlib.dll) but SIMD itself could also be used elsewhere.

> Mono.Math resides within Mono.Security, so I would be creating a
> dependency from Mono.Security to Mono.Simd. Also, Mono.Math is
> incorporated internally within corlib, which would probably mean
> interning Mono.Simd in corlib as well.
> One confounding factor is that Mono.Simd uses extension methods,
> thus depending on System.Core, and being a 2.0-only library. With
> the 1.1 world still around, incorporation of Mono.Simd into corlib
> and Mono.Security will probably require some precision cuts to get
> 1.1 working independently of Mono.Simd, while letting 2.0 utilize
> it. (Another option is to reduce the dependency on the
> VectorOperations extension methods, making them normal static
> methods when built to 1.1).

These are non-issues.

> The intended outcome is that Mono's cryptographic libraries will see
> a nice speedup when run on systems supporting SIMD.

See below for a simpler approach to the same goal ;-)

> Since this is my first major delve into Mono, in a contributory
> sense, any input, corrections, or advice are welcome as I try to
> wrap my head around what actually needs to be done.

I think you got almost all the pieces correct (and they are not easy
subjects to mix together) but a few missing ones.


1. the SIMD API is not set in stone;

2. the current BigInteger API is set in stone, like all stuff in
Mono.Security.dll, because it's publicly exposed (and used). However
this does not really affect mscorlib.dll (expect from a maintenance
point of view);

3. it's likely that the SIMD code will run slower on non-SIMD platform
which are, in general, already slower architectures (at least for Mono
JIT). Making the fast, faster and the slow, slower (avoiding the later
would be nice ;-)

4. we do not want to grow mscorlib.dll with multiple implementations of
the same algorithms. Nor do we want to complexify its build (it's
already complex enough);

5. our current BigInteger is (sadly) using unsafe code - which makes it
impossible to reuse it to provide all our cryptographic code to all
Silverlight/Moonlight developers. Ideally we'll be able to remove this
(in the near future, e.g. BigInteger from .NET 4) unsafe usage, but we
definitively do not want to add more.

The *good* news is that none of this has to stop you from reaching your
stated goal :-) because the cryptographic API of the .NET framework is
plug-able - allowing you to replace almost any part of it with new ones.

So here's my suggestion:

a. Create a new assembly with your own SIMD-enabled BigInteger. From
here you can break the API as much as you want, whenever you want (or
need) [1,2,3];

b. Incrementally copy the RSA, DSA and DH code inside this assembly.
Make the (should be few) API adjustments [4];

c. Edit your machine.config file to remap the default implementation to
your SIMD assembly [3];

d. Leave mscorlib.dll alone with it's default, almost all safe,
implementations [4,5];


x. Copy other cryptographic algorithms, like hash algorithms (SHA1 being
a good candidate since it's often used), and SIMD-enable them.

y. Make a tool that compare performance of different implementations
(e.g. see Crimson for native hash support) and edit your machine.config
automagically - making it possible for everyone to automatically use the
fastest implementation available on their own computer.

z. Enjoy them and your fame ;-)


More information about the Mono-devel-list mailing list