MSDN Magazine - October 2007 - (Page 25)

Figure 5 Disassembled “+” Cache public static object Handle(object[], FastDynamicSite site1, object obj1, object obj2) { if (((obj1 != null) && (obj1.GetType() == typeof(string))) && ((obj2 != null) && (obj2.GetType() == typeof(string)))) { string text; string text1 = text = StringOps.Add(Converter.ConvertToString(obj1), Converter.ConvertToString(obj2)); return text; } return site1.UpdateBindingAndInvoke(obj1, obj2); } through all the cache checks and calls UpdateBindingAndInvoke again, which generates a new delegate. The newest delegate’s code will capture the first tests of x and y as well as the new tests, calling whichever target implementation matches the types. It’s time to take a look at the DoOperation-Add-0 delegate that the DLR generated from running the code in msdnmag.py. Go back to Reflector, and this time expand the snippets1, snippets.dll,“{} -”, and “Type$_stub_$4” nodes in the left pane. Click on the Handle method, and in the right pane you’ll see the code in Figure 5. This is the disassembled code from the IL that the DLR generated for the DoOperation-Add-0 delegate after executing “text + yourname”. If we called the yo function again, this delegate would execute. This code has some performance issues you might spot, but more on that later. You can see that the code tests whether the two arguments are strings and calls the IronPython runtime implementation of addition given two strings. If one of the arguments is not a string, then the delegate calls UpdateBindingAndInvoke to generate a new delegate. The new delegate would replace the current one (above) so that the next time DoOperation-Add-0.Invoke runs, it will call the updated delegate. I changed the msdnmag.py code so that the “text + yourname” executes on two integers for a second call to yo. I then found the second delegate that the DLR generated after the second call. It looked like Figure 6. I cleaned up the bogus temporary variables that Reflector inserted. If you do the extra experiment I did, you’ll get slightly different code. You’ll see that now the code tests if the arguments are integers. If they are, it calls the runtime helper function that implements Add on integers. The same code that I had before follows the integer test and target code. I chose to order the tests with the most recent types tested first. With profiled runs of the program, you could imagine generating all the right arguments’ tests in the optimal order. Of course, the delegate falls back to calling UpdateBindingAndInvoke in case the arguments have a new type combination that has not been seen before. You will probably notice performance issues with the code. The DLR could generate better code today, but as with any alpha release, the DLR makes trade-offs on functionality and code generation.You may notice that the code tests for a type, string, and then converts the argument to a string. There are two problems with this. The first is that the .NET Framework 2.0 JIT does not propagate type information from “if ” tests to the consequent code block. Since the Add implementation is a statically typed method, the arguments need to show up as strings to it. The second problem is the DLRgenerated code does a slow call to a runtime conversion function. The DLR could have emitted a cast operation here. The last performance issue to mention is that the DLR today does not structure tests to avoid repeating the same one. In my updated delegate that knows how to quickly add two integers or two strings, I test the arguments for null. I do this multiple times as I move through the tests when I don’t have to do that. When UpdateBindingAndInvoke searches for operation implementations, it actually asks the objects how to do the operation. It calls on the objects to provide a rule for how to perform the operation represented by the DynamicSite. The rule contains an AST for the test to perform and an AST for the target code to execute if the test is true. The DLR could perform tree transformations across the tests to optimize the delegate’s code even more. As a final point, because I used dynamic sites for There is a lot to leverage fetching members of obfrom the CLR and the jects, I have to handle DLR—garbage collection, changes to instances and dynamic types. The DLR JIT compilation, dynamic cannot assume for o.m() sites, common dynamic type that if o points to the same model, and so forth. object, then it knows exactly which m to invoke. Some languages allow types to change at run time, and they can replace members, essentially overriding a member in an instance. The DLR uses a global version counter that it increments for new types and changes to types. There are various trip wires that cause a type’s version to change, such as changing members. Any DynamicSite caches that refer to objects where their type’s version has changed will fail the cache. Then the DynamicSite will search again and update the delegate. The Big Payoff The generated DynamicSite types are generic types. Using generic types doesn’t help very much in the example Python code Figure 6 Disassembled “+” Cache Two public static object Handle(object[] FastDynamicSite site1, object obj1, object obj2) { if (((obj1 != null) && (obj1.GetType() == typeof(int))) && ((obj2 != null) && (obj2.GetType() == typeof(int)))) { return Int32Ops.Add(Converter.ConvertToInt32(obj1), Converter.ConvertToInt32(obj3)); } if (((obj1 != null) && (obj1.GetType() == typeof(string))) && ((obj2 != null) && (obj2.GetType() == typeof(string)))) { return = StringOps.Add(Converter.ConvertToString(obj1), Converter.ConvertToString(obj2)); } return site1.UpdateBindingAndInvoke(obj1, obj3); } CLR Inside Out october2007 25

Table of Contents Feed for the Digital Edition of MSDN Magazine - October 2007

Cover Contents Toolbox CLR Inside Out Basic Instincts Data Points Cutting Edge Pooled Threads WPF Threads Parallel Linq Parallel Performance Mobile Apps Test Run Foundations Windows with C++ Netting C++ .NET Matters { End Bracket } Net Nuptials

MSDN Magazine - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.