James at Love Electronics has started a discussion on implementing accelerated C# for some near native speed capability.
He is looking for community feedback…
[quote] Be able to mark certain methods or operations as Accelerated, such as complex algorithms such as those involved in DSP, IMU processing, AI (SLAM).
Only require a subset of the .NET Micro Framework, basically working with Value Types (Structures, Integers, Bytes, Floats (Could possibly implement String as a Value Type)).
Threading would be a plus, but much more complex to implement (for example, allow the Accelerated method to create threads internally, separate to the NETMF threads).
I am only thinking about creating Atomic operations (call the Accelerated C# operation, return) rather than having long running Async operations.
Implementing Device Drivers (such as SPI, I2C etc) should be implemented using existing Interop methods, Accelerated C# is only to accelerate business logic (application specific logic).[/quote]
Either or both i guess its a community question after all. It may be better to discuss on the love forum and synopsis here as the discussion started over there. I dont know what the etiquette is though
Here or there is no matter, what is important is that there is community input. So if anyone has thoughts to add then read the post on the Love forum and then comment here.
We are talking about performing AOT compilation on specific methods marked as [Accelerated]. At the moment I am working only on static methods, meaning they are designed to take a piece of logic (such as AHRS code) and removing the overhead of the Interpreter for this specific piece of code.
The reason I am only looking at allowing Value types is that when you start including things like System.IO objects and other CLR functionality, there is a lot more stuff that has to be AOT compiled, and this will contain many more objects that are unsuitable for AOT compilation. Especially items that call from C# into Interop code will definitely not be supported.
For instance.
public struct EulerAngles
{
public float X;
public float Y;
public float Z;
}
public static class AHRS
{
[Accelerated]
public static EulerAngles Calculate(float accX, float accY, float accZ)
{
// Complex AHRS code that is very slow in NETMF.
return myAngles;
}
}
You will see no change in your application, other than loosing the ability to jump into the Calculate method with VS.
The Calculate method can use EulerAngles because it is a struct (Value Type).
I hope this makes sense and at least gives points for discussion.
Yes, it is different from RLP, whereas RLP allows you to compile C libraries you can call from C# (for instance just build any number of existing C libraries and use them off the shelf), the main criteria for RLP that I’ve seen (At least on this forum) is for people wanting to accelerate a bottleneck in their code, or a piece of code that does not need to be managed.
This is the perfect solution for those kinds of scenarios.
i’d be interested in benchmarks for this…couple of questions
-is this something that happens at run time or compile time?
-doesn’t the jit compile IL code into native code on ‘first sight’ anyway? ngen’d code are not necessarily faster than jit’d code, just the initialy startup is faster.
-you are using markups/attributes…which means i think you’ll be invoking code that will use reflection, i think. how costly will that be?
-what about dependencies? this seems as though it would only apply to the most basic code without other .net library related dependencies, correct?
if this is something that happens at run time, it seems like something like this will come down to who is faster…the jit or interpreting the attributes…both will lead to native code compilation/execution.
interested in hearing more and seeing some benchmarks
Also James (James? I think Love Electronics is James?) said it’s AOT (Ahead Of Time), so there’s no reflection here. The attribute is simply there so the AOT compiler knows what to compile and what not to compile.