The Crag Of Rogue Modron

Cgal /clr

2012-02-18T10:59:00.001+01:00

Trying to use Cgal in a C++ project with Common Language Runtime support (/clr) you may encounter a few problems.

Tested with Visual Studio 2010 using Cgal 3.9 and Boost 1.49.0 beta 1, x86 build.

First ...

If the following message appears when you start your application:

The application failed to initialize properly (0xc000007b).

The problem may be due to Boost.Thread, which is required by Cgal.

According to

http://lists.boost.org/Archives/boost/2009/04/151043.php

modify

$BOOST_ROOT/libs/thread/src/win32/tss_pe.cpp

in this way:


#if (_MSC_VER >= 1400)
//#pragma section(".CRT$XIU",long,read)
#pragma section(".CRT$XCU",long,read)
#pragma section(".CRT$XTU",long,read)
#pragma section(".CRT$XLC",long,read)
        __declspec(allocate(".CRT$XLC")) _TLSCB __xl_ca=on_tls_callback;
        //__declspec(allocate(".CRT$XIU"))_PVFV p_tls_prepare = on_tls_prepare;
        __declspec(allocate(".CRT$XCU"))_PVFV p_process_init = on_process_init;
        __declspec(allocate(".CRT$XTU"))_PVFV p_process_term = on_process_term;
#else

The __declspec lines were added in order to close this ticket (Severity - Cosmetic):

https://svn.boost.org/trac/boost/ticket/2199

Second ...

If the following assertion message appears at runtime:

Wrong rounding: did you forget the -frounding-math option if you use GCC (or -fp-model strict for Intel)?

Define CGAL_DISABLE_ROUNDING_MATH_CHECK and rebuild your project.

However, you should have seen this compiler warning:

warning C4996: '_controlfp_s': Direct floating point control is not supported or reliable from within managed code.

_controlfp_s is used directly by Cgal but, from MSDN:

This function is deprecated when compiling with /clr (Common Language Runtime Compilation) or /clr:pure because the common language runtime only supports the default floating-point precision.

So you should not expect identical results if you run the same project compiled with or without Common Language Runtime support.

Invoking Native

2011-11-02T23:05:00.002+01:00

A quick overview of the different ways to call unmanaged APIs from managed code, with .Net and also with Mono.

The inspiration for this post came after reading a couple of articles. The first relating to SharpDX:

A new managed .NET/C# Direct3D 11 API generated from DirectX SDK headers

The second:

Techniques of calling unmanaged code from .NET and their speed

that in substance is on the same topic of this post but doesn't provide enough sample code, in particular for the final benchmark.

Native library

In the following examples we will use a function exported from a phantomatic library called Native.dll (Native.so for Mono on Unix/Linux), written in C and compiled with Cdecl calling convention.


//
// Native.h
//

void DoWithIntPointer(int a, int b, int* r);


//
// Native.c
//

#include "Native.h"

void DoWithIntPointer(int a, int b, int* r) {
    *r = a + b;
}

DoWithIntPointer simply calculates the sum of two integer but having parameters passed by value and by reference it will allow us to see some peculiarities.

Explicit P/Invoke

Let's start with a classic P/Invoke example:


//
// TestPInvoke.cs
//

using System.Runtime.InteropServices;

class TestPInvoke {    
    [DllImport(
        "Native.dll", 
        CallingConvention = CallingConvention.Cdecl
    )]
    private static extern void DoWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {
        int result = 0;
        DoWithIntPointer(1, 2, out result);
    }
}

The extern keyword tells the compiler that DoWithIntPointer is defined elsewhere while the DllImport attribute provides directions to trace it.

Implicit P/Invoke - C++/Cli

With C++/Cli we can write wrappers for native libraries with relative ease but it cannot be used with Mono. Here we have the C++/Cli wrapper for our Native library:


//
// NativeCppCliWrapper.cpp
//

#include "Native.h"

namespace NativeCppCliWrapper
{

using namespace System;
using namespace System::Runtime::InteropServices;

public ref class Wrapper {
public:
    static void CallDoWithIntPointer(
        Int32 a, 
        Int32 b, 
        [Out] Int32% r
    ) {
        int tmp;
        DoWithIntPointer(a, b, &tmp);
        r = tmp;
    }
};

}

After compiling, the wrapper can be used as any other assembly:


//
// TestCppCli.cs
//

using NativeCppCliWrapper;

class TestCppCli {
    public static void Main() {
        int result = 0;
        Wrapper.CallDoWithIntPointer(1, 2, out result);
    }
}

If we dig through the IL code generated by C++/Cli we can see that CallDoWithIntPointer invokes:


 IL_0004: call void modopt(
      [mscorlib]System.Runtime.CompilerServices.CallConvCdecl
   )  ''::DoWithIntPointer(int32, int32, int32*)

And DoWithIntPointer is described by the following metadata:


.method assembly static pinvokeimpl("" lasterr cdecl)
 void modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)  DoWithIntPointer (
  int32 '',
  int32 '',
  int32* ''
 ) native unmanaged preservesig 
{
 .custom instance void
 [mscorlib]System.Security.SuppressUnmanagedCodeSecurityAttribute::.ctor() = (
  01 00 00 00
 )
}

Converted in C# (with IlSpy):


[SuppressUnmanagedCodeSecurity]
[DllImport("", 
    CallingConvention = CallingConvention.Cdecl, 
    SetLastError = true
)]
[MethodImpl(MethodImplOptions.Unmanaged)]
internal unsafe static extern void DoWithIntPointer(
    int, 
    int, 
    int*
);

Does this remind us of anything? Yes, it is very similar to the extern declaration that we have seen previously but among the differences we can note an attribute called SuppressUnmanagedCodeSecurity. MSDN tells us that:

This attribute is primarily used to increase performance; however, the performance gains come with significant security risks.

Security risks apart it can be used with explicit P/Invoke, it is not an exclusive of C++/Cli.

In other situations the native code is called in a more sophisticated way, for example if we poke inside IL code of SlimDX we can find things like this:


.method public hidebysig 
 instance valuetype SlimDX.Result Optimize () cil managed 
{
 // Method begins at RVA 0xd0824
 // Code size 25 (0x19)
 .maxstack 3

 IL_0000: ldarg.0
 IL_0001: call instance valuetype 
  IUnknown* SlimDX.ComObject::get_UnknownPointer()
 IL_0006: dup
 IL_0007: ldind.i4
 IL_0008: ldc.i4.s 68
 IL_000a: add
 IL_000b: ldind.i4
 IL_000c: calli System.Int32 modopt(
   System.Runtime.CompilerServices.IsLong
  ) modopt(
   System.Runtime.CompilerServices.CallConvStdcall
  )(System.IntPtr)
 IL_0011: ldnull
 IL_0012: ldnull
 IL_0013: call valuetype SlimDX.Result 
  SlimDX.Result::Record
  <class SlimDX.Direct3D11.Direct3D11Exception>(
   int32, object, object
  )
 IL_0018: ret
}

The calli instruction is used to invoke a native method given the address of the method itself. We will see how to take advantage of calli without C++/Cli in the last example.

Dynamic P/Invoke

In order to employ the previos techniques tha native library must be know at compile time, while it must be located in a certain path at runtime. With dynamic P/Invoke we can obtain a greater degree of flexibility.

In the next example we will benefit by an assembly called CSLoadLibrary but slightly modified, in particular to run on Unix/Linux via Mono (see the download link at the end of this post for the modified version). CSLoadLibrary contains an UnmanagedLibrary class that provides access to native libraries through standard Windows APIs (LoadLibrary, GetProcAddress, FreeLibrary) or Unix/Linux counterparts (dlopen, dlsym, dlclose).


//
// TestDelegate.cs
//

using System.Runtime.InteropServices;
using CSLoadLibrary;

class TestDelegate {
    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    delegate void DelegateWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {
        UnmanagedLibrary nativeLib = 
            new UnmanagedLibrary(
                "Native"
            );
        
        DelegateWithIntPointer doWithIntPointer = 
            nativeLib.GetUnmanagedFunction
                <DelegateWithIntPointer>(
                "DoWithIntPointer"
            );

        int result = 0;
        doWithIntPointer(1, 2, out result);
    }
}

In practice, given the name of the native library to load, an UnmanagedLibrary object is instantiated. Then, with GetUnmanagedFunction we obtain a delegate pointing to our native function, DoWithIntPointer. Naturally the signature of the delegate must match the signature of the native function.

Dynamic P/Invoke – Explicit P/Invoke

This time, instead of using CSLoadLibrary, the delegate is created via Reflection, replicating the extern declaration shown in the Explicit P/Invoke example.


//
// TestDynamicS.cs
//

using System;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;
using System.Security;

class TestDynamicS {
    delegate void DelegateWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {
        DelegateWithIntPointer doWithIntPointer = 
            GetDynamicSDelegate
                <DelegateWithIntPointer>(
                "Native", 
                "DoWithIntPointer", 
                CallingConvention.Cdecl
            );
            
        int result = 0;
        doWithIntPointer(1, 2, out result);
    }

    private static TDelegate GetDynamicSDelegate
        <TDelegate>(
        string libraryName, 
        string entryPoint, 
        CallingConvention callingConvention
    ) where TDelegate : class 
    {
        Type delegateType = typeof(TDelegate);
        MethodInfo invokeInfo = delegateType.GetMethod("Invoke");
        // Gets the return type for the P/Invoke method.
        Type invokeReturnType = invokeInfo.ReturnType;
        // Gets the parameter types for the P/Invoke method.
        ParameterInfo[] invokeParameters = 
            invokeInfo.GetParameters();
        Type[] invokeParameterTypes = 
            new Type[
                invokeParameters.Length
            ];
        for (int i = 0; i < invokeParameters.Length; i++) {
            invokeParameterTypes[i] = 
                invokeParameters[i].ParameterType;
        }

        // Defines an assembly with a module and a type.
        AssemblyName assemblyName = 
            new AssemblyName(
                "TestAssembly"
            );
        AssemblyBuilder assemblyBuilder = 
            AppDomain.CurrentDomain.DefineDynamicAssembly(
                assemblyName, 
                AssemblyBuilderAccess.Run
            );
        ModuleBuilder moduleBuilder = 
            assemblyBuilder.DefineDynamicModule(
                "TestModule"
            );
        TypeBuilder typeBuilder = 
            moduleBuilder.DefineType(
                "TestDynamicS"
            );
            
        //Defines a P/Invoke method called Invoke.
        MethodBuilder methodBuilder = 
            typeBuilder.DefinePInvokeMethod(
                "Invoke", 
                libraryName + ".dll", 
                entryPoint, 
                MethodAttributes.Public | 
                    MethodAttributes.Static | 
                    MethodAttributes.PinvokeImpl,
                CallingConventions.Standard, 
                invokeReturnType, 
                invokeParameterTypes, 
                callingConvention, 
                CharSet.Ansi
            );
        methodBuilder.SetImplementationFlags(
            methodBuilder.GetMethodImplementationFlags() | 
            MethodImplAttributes.PreserveSig
        );
        
        // Adds SuppressUnmanagedCodeSecurityAttribute to 
        // the method.
        Type attributeType = 
            typeof(
                SuppressUnmanagedCodeSecurityAttribute
            );
        ConstructorInfo attributeConstructorInfo = 
            attributeType.GetConstructor(
                new Type[] {}
            );
        CustomAttributeBuilder attributeBuilder = 
            new CustomAttributeBuilder(
                attributeConstructorInfo, 
                new object[] {}
            );
        methodBuilder.SetCustomAttribute(attributeBuilder);

        // Finishes the type.
        Type newType = typeBuilder.CreateType();
        
        object tmp = 
            (object)Delegate.CreateDelegate(
                delegateType, 
                newType.GetMethod("Invoke")
            );
        return (TDelegate)tmp;
    }
}

Though we are adding the SuppressUnmanagedCodeSecurity attribute, it is not essential.

Dynamic P/Invoke - Emit Calli

The last example is more complicated. Here again, we make use of UnmanagedLibrary to get the native function's address. Then, through Reflection, we create a dynamic method which internally passes the address of the native function to calli, the instruction seen previously.


//
// TestCalli.cs
//

using System;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;
using CSLoadLibrary;

class TestCalli {
    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    delegate void DelegateWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {        
        UnmanagedLibrary nativeLib = 
            new UnmanagedLibrary(
                "Native"
            );
        IntPtr nativeMethodAddress = 
            nativeLib.GetUnmanagedFunctionAddress(
                "DoWithIntPointer"
            );
        DelegateWithIntPointer doWithIntPointer = 
            GetCalliDelegate
                <DelegateWithIntPointer>(
                nativeMethodAddress
            );
        int result = 0;
        doWithIntPointer(1, 2, out result);
    }
    
    private static TDelegate GetCalliDelegate
        <TDelegate>(
        IntPtr methodAddress
    ) where TDelegate : class
    {
        Type delegateType = typeof(TDelegate);
        MethodInfo invokeInfo = delegateType.GetMethod("Invoke");
        // Gets the return type for the dynamic method and calli.
        // Note: for calli, a type such as System.Int32& must be
        // converted to System.Int32* otherwise the execution 
        // will be slower.
        Type invokeReturnType = invokeInfo.ReturnType;
        Type calliReturnType = 
            GetPointerTypeIfReference(
                invokeInfo.ReturnType
            );
        // Gets the parameter types for the dynamic method 
        // and calli.
        ParameterInfo[] invokeParameters = 
            invokeInfo.GetParameters();
        Type[] invokeParameterTypes = 
            new Type[
                invokeParameters.Length
            ];
        Type[] calliParameterTypes = 
            new Type[
                invokeParameters.Length
            ];
        for (int i = 0; i < invokeParameters.Length; i++) {
            invokeParameterTypes[i] = 
                invokeParameters[i].ParameterType;
            calliParameterTypes[i] = 
                GetPointerTypeIfReference(
                    invokeParameters[i].ParameterType
                );
        }

        // Defines the dynamic method.
        DynamicMethod calliMethod = 
            new DynamicMethod(
                "CalliInvoke", 
                invokeReturnType, 
                invokeParameterTypes, 
                typeof(TestCalli), 
                true
            );
            
        // Gets an ILGenerator.
        ILGenerator generator = calliMethod.GetILGenerator();   
        // Emits instructions for loading the parameters into 
        // the stack.
        for (int i = 0; i < calliParameterTypes.Length; i++) {
            if (i == 0) {
                generator.Emit(OpCodes.Ldarg_0);
            } else if (i == 1) {
                generator.Emit(OpCodes.Ldarg_1);
            } else if (i == 2) {
                generator.Emit(OpCodes.Ldarg_2);
            } else if (i == 3) {
                generator.Emit(OpCodes.Ldarg_3);
            } else {
                generator.Emit(OpCodes.Ldarg, i);
            }
        }
        // Emits instruction for loading the address of the
        //native function into the stack.
        switch (IntPtr.Size) {
            case 4:
                generator.Emit(
                    OpCodes.Ldc_I4, 
                    methodAddress.ToInt32()
                );
                break;
            case 8:
                generator.Emit(
                    OpCodes.Ldc_I8, 
                    methodAddress.ToInt64()
                );
                break;
            default:
                throw new PlatformNotSupportedException();
        }
        // Emits calli opcode.
        generator.EmitCalli(
            OpCodes.Calli, 
            CallingConvention.Cdecl,
            calliReturnType, 
            calliParameterTypes
        );
        // Emits instruction for returning a value.
        generator.Emit(OpCodes.Ret);

        object tmp = 
            (object)calliMethod.CreateDelegate(
                delegateType
            );
        return (TDelegate)tmp;
    }
    
    private static Type GetPointerTypeIfReference(Type type) {
        if (type.IsByRef) {
            return Type.GetType(type.FullName.Replace("&", "*"));
        }
        return type;
    }
}

The method GetPointerTypeIfReference converts the type of a parameter like Int32& to Int32*, otherwise calli executes correctly but results slower.

Benchmark

Hardware: CPU Intel Core i3-2310M 2.1 GHz, RAM 4 GB.
Software: VMware Player 3.1.4. on Windows 7 x64.

[ms] x 100,000,000 iterations

SUC means that the test has been executed with the SuppressUnmanagedCodeSecurity attribute.

void DoWithIntPointer(int a, int b, int* r)
	.Net 4	Mono 2.10.6	Mono 2.10.5	Mono 2.6.7
	Windows	Windows	Ubuntu	Debian
	XP x32	XP x32	Oneiric amd64	squeeze i386
Expl. P/I	8117	12001	2346	3657
Expl. P/I SUC	3681	3485	2344	3708
C++/Cli	4760
Dyn. P/I	19309	68303	2603	4431
Dyn. P/I SUC	7361	59718	2615	4514
Dyn. P/I Expl. SUC	4497	4419	2480	4398
Dyn. P/I Calli	4136	4249	1885	4353

void DoWithDoublePointer(double a, double b, double* r)
	.Net 4	Mono 2.10.6	Mono 2.10.5	Mono 2.6.7
	Windows	Windows	Ubuntu	Debian
	XP x32	XP x32	Oneiric amd64	squeeze i386
Expl. P/I	8215	14328	2194	4819
Expl. P/I SUC	4203	6658	2207	4826
C++/Cli	5576
Dyn. P/I	22881	68789	3658	7260
Dyn. P/I SUC	7478	60425	3780	7251
Dyn. P/I Expl. SUC	4247	6627	3655	7294
Dyn. P/I Calli	3925	3766	3050	6766

Conclusion

The above results seem a bit weird and the only certain thing appears to be that Dynamic P/Invoke is always faster if we resort to calli. Anyway, we have seen different ways to invoke unmanaged code from managed code, each with its own pros and cons, and if necessary we can use them or conduct further tests.

Download

Benchmark source code.

Other resources

About interoperability:
Interop with Native Libraries
Invoke Native C++ DLL from .NET Code

About calli:
Calli is not Verifiable
C#/.NET: Why is Calli Faster Than a Delegate Call?
OpenGL Import für Delphi .Net

Polygon Clipping: a Wrapper, a Benchmark

2011-04-17T11:21:00.006+02:00

An experiment about six open source polygon clipping libraries that have been benchmarked after being wrapped for use with .Net.

Note that there could be errors and however no consideration is made about the robustness or optimization of the libraries so this benchmark must be taken with "a grain of salt".

LAST UPDATE - AUGUST 14, 2011

The six libraries

- Boost.Geometry -

Version Subversion trunk rev. 73602
License Boost v1.0

Boost.Geometry, also known as Ggl, can be used with Mpir (a Gmp fork) or with TTMath, for more precision but with a significant slowdown.

- Boost.Polygon -

Version Subversion trunk rev. 72191
License Boost v1.0

Boost.Polygon, also known as Gtl, can be used with Mpir with no speed penalty.

- Clipper -

Version 4.4.0
License Boost v1.0

- Geos -

Version 3.3.0
License LGPL

- Gpc -

Version 2.32
License Free for non-commercial use / Commercial

- KBool -

Version 2.1
License GPL v3 / Commercial

KBool source has been patched to avoid creating the file keygraphfile.key.

The guests

For comparative purposes, other libraries have been used during the benchmark.

- PolyBoolean.c20.NET -

Version 2.0.0 (demo)
License Commercial

Note that the demo version throws an exception when the number of vertices returned is a multiple of 7.

- SQL Server System CLR Types 2008 -

Version 10.50.2500.0
License Proprietary

The wrapper

A light C++/Cli wrapper that exposes only the polygon set operations (union, difference, intersection, disjoint-union).

Hardware and software

CPU - Intel Core 2 Quad Q6600 @ 2.40GHz
RAM - 4GB
OS - Windows XP x64
SDK - Win SDK v7.1 / Visual Studio 2010 Express
Settings - Default x86 release build

The benchmark – known polygons (a)

In this test one operand is a polygon that resembles a gear while the other operand is formed by a set of concentric rings. During the test the gear teeth have been increased in number and length as well as the number of rings. An intersection operation has been executed.

The first and the last operation have been executed respectively with 19 and 723347 input vertices. Boost.Geometry has been the fastest library followed by Clipper while Boost.Polygon has started slow but has scaled well.

The benchmark – known polygons (b)

In this test the polygons have been generated in a manner similar to that of the previous test.

The first and the last operation have been executed respectively with 123 and 606201 input vertices. In this case Clipper has been the fastest followed by SQL Server System Types and PolyBoolean.

The benchmark - random polygons

The operands used in this test have been obtained subtracting random triangles from a square. An intersection operation has been executed.

The first and the last operation have been executed respectively with 402 and 53359 input vertices. Boost.Geometry has been the fastest followed by SQL Server System Types and Boost.Polygon. Geos has been very slow. During the last test PolyBoolean has raised an exception ("Invalid contour orientation").

The benchmark - classic polygons

Polygons used in this test are the same ones used to test PolyBoolean (C++ version) and Clipper (see their websites).

Boost.Geometry has been the fastest followed by Clipper, SQL Server System Types and Geos. Gpc has been the slowest.

Known polygons - X32 VS X64

These are execution times obtained with 723347 input vertices as in "known polygons (a)", but in this case all has been compiled for X64 platform.

When compiled for X64 the libraries are generally faster.

Gpc – C# wrapper vs C++/Cli wrapper

Gpc has a C# wrapper and here is a comparison with the C++/Cli wrapper. The polygons have been generated as in "known polygons (b)".

Not a big difference between a P/Invoke and a C++/Cli wrapper but P/Invoke can be used with Mono.

Clipper – C# vs C++/Cli wrapper

Clipper has a C# implementation and here is a comparison with the wrapped C++ implementation. The polygons have been generated as in "known polygons (b)"

The C# implementation is slower but can be used directly with .Net and Mono.

Downloads

Wrapper source code (C++/Cli)
(source code for the libraries must be downloaded from the respective sites)

Benchmark source code and binaries (Vb.Net)
(contains only binaries for libraries released under Boost v1.0 license)

Benchmark output (txt files)

UPDATES

AUGUST 14, 2011
- Added Geos and SQL Server System Types.
- Corrected bug on closing vertex for polygons used in all the tests except the one with random polygons.

JULY 23, 2011
- Added Boost.Geometry.
- Polygons have been closed.