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
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.
public struct EulerAngles
public float X;
public float Y;
public float Z;
public static class AHRS
public static EulerAngles Calculate(float accX, float accY, float accZ)
// Complex AHRS code that is very slow in NETMF.
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.