Today's Hardware Friday post by Mario Vernari struck a cord for me. Being a Desktop Dev myself, his view was one that I could appreciate. Hardware dev is a very different world and requires you to think differently ("No? Really?" Sorry, I have this "state the obvious" condition... lol and this post shows you why...
Before going on on my graphic library for led matrix, I think it’s time to optimize a bit the code in order to get the Netduino running faster.
My job is programming application using .Net for desktop, but a PC is very rich of resources such as RAM and processor speed. Instead, the Micro Framework offers a very small environment where every byte more might have an impact on the final result.
Here is a brief bunch of tests for showing a comparison on different approaches against a same task. Sometime you don’t care about the best way to write the code, but the interesting thing is actually knowing how the things are working. You will be surprised, as I was.
The test bench.
The base program for the tests is very simple: it is an endless loop where the code under test runs interleaved by a short pause of 100ms. The comparison is mostly against different yet commonly-used types, such as Int32, Single, Double and Byte.
The timings are taken by using a scope, then watching at two output ports when they change their state.
Except for the very first, each test cycles 50 times over a 20-operations set: that for minimize the overhead due to the “for-loop”. By the way, the first test is targeted just for get the “for-loop” heaviness.
It follows the test program template:
The basic for-loop.
Since every test will use the “for-loop”, we should measure how much overhead that introduces.
Here is the snippet…
Roughly speaking, we could say that every for-loop cycle takes about 7 microseconds.
How does look the IL-opcodes generated by the compiler (restricted to the only for-loop)?
Well, it is pretty interesting digging a bit behind (or under?) the scenes. I will take advantage by the awesome ILSpy, which is a free, open-source decompiler, disassembler and much more provided by the SharpDevelop teams.
If you're not afraid of a little IL and want to see what's happening behind the scenes of the code you're writing, check out his post...