6 replies to this topic

[philvr]

The i2c MAX6651 fan controller has a tacho count time register that sets a tacho count period 0.25S, 0.5S, 1S or 2S. The tacho counter is read and the time of a fan rotation derived from the counting period set in the tacho count register and the number of pulses counted by the tacho.Questions is this. As the tacho count time register is in powers of 2, is it quicker to use a bitwise shift ( to shift the tacho counter reading right to multiply by two (left to divide by 2) or to use an integer multiply/divide operation?Does anyone know if the clr c# interpreting system would choose the most efficient operation?

[Mario Vernari]

Hello.

If I remember well, you shouldn't notice any difference between the two ways to do the same operation. Since the code is interpreted, most of the time is taken by the opcodes parsing engine, then the native operations are (mostly) much faster.

Good luck.

[Nevyn]

If I remember well, you shouldn't notice any difference between the two ways to do the same operation. Since the code is interpreted, most of the time is taken by the opcodes parsing engine, then the native operations are (mostly) much faster.

 

Also, where it does matter, a good compiler will work out that you are multiplying by a constant value which is a multiple of 2 and substitute a shift operation if it will make the code more efficient.

 

Regards,

Mark

[Mario Vernari]

Also, where it does matter, a good compiler will work out that you are multiplying by a constant value which is a multiple of 2 and substitute a shift operation if it will make the code more efficient.

 

Regards,

Mark

 

Absolutely!

Your point deserves a quick test on how the IL looks against the two cases:

Here is the source code:

 

    class Program    {        static void Main(string[] args)        {            const int k = 4;            var c = 7;            var a1 = c * k;            var a2 = c << 2;            var q = a1 + a2;            Console.WriteLine(q);        }    }

And here is the related IL, compiled as "release" (it's an ordinary .Net console app, but the IL should be the same):

.method private hidebysig static	 void Main (		string[] args	) cil managed {	// Method begins at RVA 0x2050	// Code size 21 (0x15)	.maxstack 2	.entrypoint	.locals init (		[0] int32 c,		[1] int32 a1,		[2] int32 a2,		[3] int32 q	)	IL_0000: ldc.i4.7	IL_0001: stloc.0	IL_0002: ldloc.0	IL_0003: ldc.i4.4	IL_0004: mul	IL_0005: stloc.1	IL_0006: ldloc.0	IL_0007: ldc.i4.2	IL_0008: shl	IL_0009: stloc.2	IL_000a: ldloc.1	IL_000b: ldloc.2	IL_000c: add	IL_000d: stloc.3	IL_000e: ldloc.3	IL_000f: call void [mscorlib]System.Console::WriteLine(int32)	IL_0014: ret} // end of method Program::Main

Apparently there's no recognition on the possible optimization (despite the "optimization" check). Probably on a PC the JIT will perform the final touch.

Cheers

[philvr]

Is it worth testing the optimisation abilities of the Microsoft Development Environment (Visual Studio) in  greater depth?   If the  Development Environment was originally designed for producing desktop and server based applications could it be that optimisations produced for embedded system code are not what they could be ? What if  the environment had been aimed at producing  embedded code right from the beginning?   We are not talking about producing optimised machine code (are we?) but an intermediate language understood by the CLI. That also raises the question of how the JIT element fits in....   (please correct me if I am wrong)

[Mario Vernari]

Is it worth testing the optimisation abilities of the Microsoft Development Environment (Visual Studio) in  greater depth?   If the  Development Environment was originally designed for producing desktop and server based applications could it be that optimisations produced for embedded system code are not what they could be ? What if  the environment had been aimed at producing  embedded code right from the beginning?   We are not talking about producing optimised machine code (are we?) but an intermediate language understood by the CLI. That also raises the question of how the JIT element fits in....   (please correct me if I am wrong)

 

There's no JIT in the Micro Framework: the IL-opcodes are interpreted.

From this viewpoint it's easier to see what a piece of code will actually do once in the magic board!

Cheers

[philvr]

Thanks for clarifying - Admittedly I don't fully understand the process involved - I'll do some background reading  tonight, promise!