Beautiful Code [29]
generator.Emit(OpCodes.Ldc_I4_S, 255);
And now we're finally ready to store the byte in the destination array. The dst array is already on the stack, the iDst index is already on the stack, and the value to be stored in the array is on the stack. The Stelem_I1 instruction stores a one-byte value into the array:
generator.MarkLabel(labelDone);
generator.Emit(OpCodes.Stelem_I1);
We're now at the bottom of the iDst loop, equivalent to line 30 of Example 8-2. The iDst local variable must now be incremented and compared to the number of bytes in the array. If it's less, the code branches to the top of the loop:
generator.Emit(OpCodes.Ldloc_0); // Put iDst on stack
generator.Emit(OpCodes.Ldc_I4_1); // Put 1 on stack
generator.Emit(OpCodes.Add); // Add 1 to iDst
generator.Emit(OpCodes.Dup); // Duplicate
generator.Emit(OpCodes.Stloc_0); // Store result in iDst
generator.Emit(OpCodes.Ldc_I4, cBytes); // Put cBytes value on stack
generator.Emit(OpCodes.Blt, labelTop); // Go to top if iDst < cBytes
After the loop is finished, the generated method concludes with a return instruction:
generator.Emit(OpCodes.Ret);
All the Intermediate Language code has now been generated. The DynamicMethod instance created at the beginning of FilterMethodIL is complete and ready to be executed, or invoked, as the following method name implies. The second argument to Invoke specifies the two arguments to the generated method as the src and dst arrays:
dynameth.Invoke(this, new object[] { src, dst });
}
And that concludes FilterMethodIL. The DynamicMethod object and the ILGenerator object are now out of scope, and the memory they occupied can be reclaimed by the .NET garbage collector.
Algorithms written in low-level languages are usually faster than those written in high-level languages, and custom algorithms are almost always faster than generalized algorithms. By customizing an algorithm in Intermediate Language on the fly right before it's used, we seem to have the best of both worlds. The algorithm is generalized until it has to be customized, and then it's customized with efficient code.
The downside is that you need to become a compiler writer of sorts, and breach that barrier between code and data, thus entering a strange netherworld where code and data become mirror images of each other.
FilterMethodIL was surely a lot of work, but how well does it perform? Generally, FilterMethodIL, which generates Intermediate Language instructions on the fly, runs in about one-quarter of the time hogged by the straight C# version, FilterMethodCS, and sometimes better.
Now, you might regard FilterMethodIL as ugly, and I'd be willing to concede that it sure isn't the prettiest code I've ever seen. But when an algorithm clocks in at a quarter of the execution time of some earlier code, then the only word that I find appropriate is beautiful.
Beautiful Concurrency > A Simple Example: Bank Accounts
24. Beautiful Concurrency
Simon Peyton Jones
The free lunch is over.[*] We have grown used to the idea that our programs will go faster when we buy a next-generation processor, but that time has passed. While that next-generation chip will have more CPUs, each individual CPU will be no faster than the previous year's model. If we want our programs to run faster, we must learn to write parallel programs.[]
[*] Herb Sutter, "The free lunch is over: a fundamental turn toward concurrency in software," Dr. Dobb's Journal, March 2005.
[] Herb Sutter and James Larus, "Software and the concurrency revolution," ACM Queue, Vol. 3, No. 7, September 2005.
Parallel programs execute in a nondeterministic way, so they are hard to test, and bugs can be almost impossible to reproduce. For me, a beautiful program is one that is so simple and elegant that it obviously has no mistakes, rather than merely having no obvious mistakes.[] If we want to write parallel programs that work reliably, we must pay particular attention to beauty. Sadly, parallel programs are often less beautiful than their sequential cousins; in particular