Go FORTH and Code

[taylorza]

@Blue Hair Bob

When are you going to want alpha testers?

I will clean up the managed code to Forth interface this weekend and provide a preview version via code share.

[taylorza]

@Architect

P.S.
I hope the bank crisis didn’t hit you hard

Thanks, we live in interesting times… After the last 2 weeks everyone knows Cyprus

[leforban]

@taylorza

@ leforban - You are correct, the test is not of the computational complexity, but the loop iteration. I just did not want to do nothing in the loop otherwise the compiler would optimize it away and I also wanted to make use of the stack in the Forth version to be as fair as possible. And at the same test the manipulation of the managed array from the Forth code.

I believe that .NETMF would be doing a left shift since the firmware is written in C and as you say modern compilers will issue a left shift.

In the same way the Forth compiler is doing the same thing and the following instruction is emitted for the 2*

mov	r2, r2, asl #1

That makes sense. To be more precise, I think we should inspect deeper what happens in the IL code.

[taylorza]

@ leforban - The .NETMF version probably does not perform a shift because the generated IL is

IL_00a3:  ldc.i4.2
IL_00a4:  mul

And the .NETMF intepreter will call NumericMul when the token for ‘mul’ is encountered in the code stream. The problem here is that NumericMul will take the two values off the stack and multiply them, but this is at runtime and therefore to late to further optimize the code. IL.

So I changed the code to explicitly use the ‘<<’ operator which results in the following IL

IL_00a3:  ldc.i4.1
IL_00a4:  shl

This calls to NumericShl which does the expected shift. There was a performance improvement, but not much. The .NETMF code with the shift executes in

453ms the Forth version is at 24 ms (I did some minor improvements and gained a little over a millisecond)

The real overhead is all the extra work .NETMF does to ensure that your code is not misbehaving ie. accessing beyond the bounds of an array, checking numeric overflows, stack under/over flows etc. All good things of course and this is what you trade for the extra performance.