Temps de lecture : 4 min.

Hybridizer supports generics and virtual functions. These concepts allow writing flexible code with type parameters, defering actual behavior resolution to type instanciation by client code. These are fondamental features of modern languages, easing encapsulation, code factorization and concepts expression.

However in C#, type parameters are resolved at runtime, which comes with a significant performance penalty. Hybridizer maps them to C++ templates, which are resolved at compile time. As such, templates allow inlining and interprocedural optimization as in plain C code. Performance penalty is therefore inexisting.

As an example, we will demonstrate usage of generics on a fun mathematical example : the resolution of heat equation with random walks.

Mathematic background

Given a connected bounded 2D domain Ω in 2, its border Ω and a function 𝑓∈:L2(Ω), we search 𝑢 such as:

Δ𝑢=0 on Ω

𝑢=𝑓 on ∂Ω

Classic ways to numerically solve this problem involve finite elements or similar discretization methods which come with different regularity constraits on Ω.

It happens we can solve it using montecarlo methods by launching brownian motions. For each point (𝑥,𝑦) in Ω we launch 𝑁 random walks. For each random walk, we wait until it reaches Ω and sample the temperature at exit point. We then sum all those exit temperatures and divide by 𝑁 to get the numerical solution :

This method is quite slow (compared to finite elements or similar). But it has some advantages:

  • It can easily be distributed among many threads (all points are independants)
  • It’s possible to compute the solution at a specific location
  • Ω has almost no regularity constraint (external cone)
  • Absolutely no memory footprint (except for the solution)
  • It works similarly in higher dimensions

Full explanations can be found on this old research report (in french).


We structured our code as would be a generic mathematical solver. The main class is MonteCarloHeatSolver, which takes a I2DProblem to solve it.
This code is generic and solves a problem described by an interface:

 public class MonteCarloHeatSolver
  I2DProblem _problem;
 public MonteCarloHeatSolver(I2DProblem problem)
  _problem = problem;
 public void Solve()
 int stopX = _problem.MaxX();
 int stopY = _problem.MaxY();
 for (int j = 1 + threadIdx.y + blockIdx.y * blockDim.y; j < stopY; j += blockDim.y * gridDim.y) {
 for (int i = 1 + threadIdx.x + blockIdx.x * blockDim.x; i < stopX; i += blockDim.x * gridDim.x) {
  float2 position;
  position.x = i;
  position.y = j;

where actual resolution (geometry related) is deferred to a I2DProblem. The call to Solve (virtual) won’t be matched to templates. But the Hybridizer will handle this and dispatch this call correctly at runtime. This will cost a vtable lookup, but only once per thread. Performance critical code is in the random walk and the boundary conditions, which are generic parameters of the 2D problem.

An example of C# code instanciation can be:

 var problem = new SquareProblem<SimpleWalker, SimpleBoundaryCondition>(N, iterCount);
 var solver = new MonteCarloHeatSolver(problem);

We then have two interfaces describing random walks and boundary conditions :

 public interface IRandomWalker
 void Init();
 void Walk(float2 f, out float2 t);
 public interface IBoundaryCondition
 float Temperature(float x, float y);

These interfaces are decorated with [HybridTemplateConcept] which tells the Hybridizer that these types will be used as type parameters. They can be extended by actual classes such as:

 public struct SimpleBoundaryCondition : IBoundaryCondition
 public float Temperature(float x, float y)
 if ((x >= 1.0F && y >= 0.5F) || (x <= 0.0F && y <= 0.5F))
 return 1.0F;
 return 0.0F;

Generic types using these interfaces have to tell the hybridizer how they want it to generate template code from generics. This is again done by using attributes:

For example:

 [HybridRegisterTemplate(Specialize = typeof(SquareProblem<SimpleWalker, SimpleBoundaryCondition>))]
 public class SquareProblem<TRandomWalker, TBoundaryCondition>: I2DProblem 
  where TRandomWalker : struct, IRandomWalker 
  where TBoundaryCondition: struct, IBoundaryCondition
  // other interface methods implementations
  // ...
 public void Solve(float2 position)
  TRandomWalker walker = default(TRandomWalker);
  TBoundaryCondition boundaryCondition = default(TBoundaryCondition);
  walker.Init(); // generic parameter method call -- will be inlined
 float temperature = 0.0F;
 float size = (float)_N;
 for (int iter = 0; iter < _iter; ++iter)
  float2 f = position;
 while (true)
  float2 t;
  walker.Walk(f, out t); // generic parameter method call -- will be inlined
  // when on border, break
 if(t.x <= 0.0F || t.y >= size || t.x >= size || t.y <= 0.0F)
  // generic parameter method call -- will be inlined
  temperature += boundaryCondition.Temperature((float)t.x * _h, (float)t.y * _h);
  // otherwise continue walk
  f = t;
  _inner[((int)(position.y - 1)) * (_N - 1) + (int)(position.x - 1)] = temperature * _invIter;
 [HybridRegisterTemplate(Specialize = typeof(TetrisProblem<SimpleWalker, TetrisBoundaryCondition>))]
 public class TetrisProblem<TRandomWalker, TBoundaryCondition> : I2DProblem
  where TRandomWalker : struct, IRandomWalker
  where TBoundaryCondition : struct, IBoundaryCondition
  // actual interface implementation


Dispatchant calls

Virtual functions trigger a callvirt in the MSIL.

IL_005e: callvirt instance void MonteCarloHeatEquation.I2DProblem::Solve

Profiling the generated code with nvvp shows us that a vtable is generated by the Hybridizer (ensuring the right method is called):

Generics and templates

On the other hand, IRandomWalker and IBoundaryCondition type parameters are mapped to templates. Their methods are therefore inlined, as shown in this nvvp profiling:

By the way: the images above show that your C# code is linked to the sass in the profiler. See our post about debugging and profiling


With few restrictions, you can safely use generics type parameters and dispatchant calls in your C# code. Hybridizer will map that to the correct concept (vtable or template) as your required for.
Dispatchant calls give you full flexibility of an inheritance hierarchy, but come at a performance cost. On the other hand, generics deliver full performance (inlined calls), as long as the right metadata has been provided.