MSDN Magazine - October 2007 - (Page 24)

It contains explicit representation of runtime method invocations (the call to Print) rather than actions that compile to dynamic sites (the node for “text + yourname”). The DLR AST also contains nodes that force results of expressions to pop off the stack so that the code adheres to Python semantics. Looking at Generated Code Now that you’ve seen how the process starts up and performs the parsing, let’s look at some generated code. The easiest way to do this is to use switches for ipy.exe and Lutz Roeder’s Reflector program. The switches cause ipy.exe to generate static code (as opposed to Lightweight Code Generation or dynamic methods) and save it to disk. Download Reflector from aisto.com/roeder/dotnet/ and then invoke the following command line while in the bin debug directory where you built ironpython.sln: ipy.exe -D -X:SaveAssemblies -X:StaticMethods msdnmag.py You’ll find two files in the directory afterwards, snippets1.dll and msdnmag.exe. Now launch Reflector on these files with this command line (filling in the absolute path as necessary): C:\where\you\put\reflector.exe snippets1.dll, msdnmag.py You can look down the list of DLLs and EXEs to find msdn and snippets1. Expand msdnmag, msdnmag.exe,“{} -”, and finally “__ main__$mod_2”. Now double-click the Initialize method. This is the body of the msdnmag.py file. You should see the disassembled source code from the IL that the DLR generated. If you have used Reflector before, you know that it is a great tool, but it also has a few flaws. It can generate extra temporary variables for example, so you need to take the C# code you see with a grain of salt. I won’t dwell on the Initialize function, but you Dynamic sites allow dynamic can see that yo is being set language code to run fast. to the result of the call to They manage the method MakeFunction, as you saw in the AST. You can see that caching for performing Initialize then calls the runspecific operations on time helper PythonOps. specific types of objects. Print on the result of invoking yo. Notice the fragment “Call-Simple-1.Invoke”. The Call-Simple-1 object is part of the method caching mechanism. I will explain the method caching further by exploring how it shows up in the yo function. Let’s look at the yo function. Double-click yo$1 in the left pane. You can see where it sets text to be “hello,” and where it returns the result of “DoOperation-Add-0.Invoke(text, yourname)”. That is the essence of the code I wrote in Python. In a moment I will focus on DoOperation-Add-0, which is the object that caches method lookup results. I’ll also look at some of the runtime-generated functions in snippets1, as I drill into DoOperation-Add-0. namic language implementations. You can see objects in the generated code such as Call-Simple-1 and DoOperation-Add-0, which are instances of derived types from DynamicSite . I’ll briefly explain the caching theory here, but you can search the Web for “dynamic language method caching” or “polymorphic inline method caching” for more information. Dynamic language performance is hindered by the extra checks and searches that occur at each call site. Straightforward implementations have to repeatedly search class precedence lists for members and potentially resolve overloads on method argument types each time you execute a particular line of code. In an expression such as o.m(x, y) or x + y, dynamic languages need to check exactly what kind of object o is, what is m bound to for o, what type x is, what type y is, or what “+” means for the actual runtime type of x and y. In a statically typed language (or with enough type hints in the code and type inferencing), you can emit exactly the instructions or runtime function calls that are appropriate at each call site. You can do this because you know from the static types what is needed at compile time. Dynamic languages provide great productivity enhancements and powerful terse expressions due to their dynamic capabilities. However, in practice code tends to execute on the same types of objects each time. This means you can improve performance by remembering the results of method searches the first time a section of code executes. For example, with x + y, if x and y are integers the first time that expression executes, we can remember a code sequence or exactly what runtime function performs addition given two integers. Then each time that expression executes, there is no search involved. The code just checks that x and y are integers again, and dispatches to the right code with no searching. The result can literally be reduced to inlined code generation with a couple of type checks and an add instruction, depending on the semantics of an operation and method caching mechanisms used. How DynamicSite Objects Work Static language compilers can select methods or emit specific code at compile time to perform operations such as addition, member fetching, and indexing. Since the DLR cannot always know at compile time what to emit, it emits code to call an Invoke method on a DynamicSite object. This object captures the operation and a delegate (called by Invoke) that contains the caching logic. This caching logic is updated each time the delegate sees a new combination of argument types at run time. (Note that delegates actually wrap pointers to functions, but, for brevity, I use delegate as if it is the function.) That’s the simple story; next up is a more detailed look. The delegate starts out with one call in it to UpdateBindingAndInvoke. The first time a call site executes (let’s just consider x + y), UpdateBindingAndInvoke queries the arguments for an Add operation implementation for the type of x and the type of y. If it gets one, it generates a new delegate that encodes a check for x and y having the same types you just saw. In a later call, if x and y have the same types, the new delegate code calls the implementation that we got. If x or y have a different type in a later call, the delegate falls Understanding Dynamic Sites Dynamic sites allow dynamic language code to run fast. They manage the method caching for performing specific operations on specific types of objects. The dynamic sites mechanism the DLR uses is based on research and experience with tried-and-true dy24 msdnmagazine CLR Inside Out http://aisto.com/roeder/dotnet/

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.