1 / 40

Discussion

Discussion. Demographics of the developer community What made “the best C++ compiler” in 1980? What’s changed since 1980?. Introduction to .NET. These slides are from the original introduction to .NET, in October 2000. Common Language Runtime. Frameworks. Base Classes.

elvin
Download Presentation

Discussion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Discussion • Demographics of the developer community • What made “the best C++ compiler” in 1980? • What’s changed since 1980?

  2. Introduction to .NET These slides are from the original introduction to .NET, in October 2000

  3. Common Language Runtime Frameworks Base Classes Common Language Runtime ExecutionSupport Security IL to native code compilers GC, stack walk, code manager Class loader and layout

  4. Multiple Languages • Common type system • Object-oriented in flavor • Procedural languages well-supported • Functional languages possible • CLS guides frameworks design • Rules for wide reach • All .NET Framework functionality available • Over 15 languages investigated • Most are CLS consumers • Many are CLS extenders

  5. Metadata: Creation And Use Reflection Source Code Serialization (e.g. SOAP) Designers Compiler Other Compiler Debugger Metadata (and code) Type Browser Profiler Proxy Generator Schema Generator XML encoding (SDL or SUDS)

  6. Execution Model VB VC ... Script NativeCode Install timeCode Gen IL Common Language Runtime “Econo”-JITCompiler Standard JITCompiler NativeCode

  7. Managed Code • Managed code provides... • Metadata describing data • Location of references to objects • Exception handling tables • So runtime can provide… • Exception handling • Security • Automatic lifetime management • Debugging and profiling

  8. Runtime Control Flow Assembly ClassLoader First reference to type IL to nativecode compiler ExecutionSupport ManagedNativeCode First call to method CodeManagers SecuritySystem CPU

  9. Compiling IL To Native • “Econo” JIT • Generates unoptimized native code • Code can be discarded and regenerated • “Standard” JIT • Generates optimized native code • Includes verification of IL code • Install time code generation • Done at install time • Reduces start-up time • Native code has version checks and reverts to runtime JIT if they fail

  10. Managed Data • Layout Provided by Runtime • Usually automatic • Metadata can specify • Order • Packing • Explicit layout • Lifetime Managed by Runtime (GC) • Working set is compacted • Data is moved • Object references are updated • No more intrusive than a page fault

  11. Calling Unmanaged Code Unmanaged NativeCode Common Language Runtime “Econo”-JITCompiler Standard JITCompiler Managed NativeCode

  12. Crossing The Boundary • Mode transition for code manager • Calling conventions differ on x86 • Fast, rarely more than register shuffle • Data type marshalling • Representations may not be the same • Pinning, copying, and/or reformatting needed • Custom marshalling supported • The IL to native compilers help • In-line code transition and simple marshalling • Per call site cost is very low • Plus a small cost on entry to a procedure that can make calls across boundary

  13. Some Statistics In the 3 years since we launched: • 50% of professional developers use .NET • 120M copies have been downloaded • 85% of consumer PCs sold in 2004 have .NET pre-installed • 58% of business PCs sold in 2004 have .NET pre-installed • HP printers/scanners/cameras install .NET (3M copies of .NET / year)

  14. Discussion • How does the move to managed code affect the compiler? • How does the move to Web servers and Web services affect the compiler? • What makes “the best Java compiler”? • What makes “the best C++ compiler” in 2005?

  15. Generics One of the major features added in Version 2.0 of the CLR, to be release later this year (2005)

  16. In English . . . Instead of defining StackOfInt, StackOfString, etc., use class Stack<T> { void Push(T item) { … } T Pop() { … } T TopOfStack() { … } } static Stack<int> IntStack; static Stack<string> StringStack; • Type safe (compile and design time support) • Shared code (better perf, easier maintenance)

  17. Polymorphic Programming Languages Standard ML Eiffel O’Caml C++ Ada Clu GJ Haskell Mercury Miranda Pizza

  18. Widely-usedPolymorphic Programming Languages C++

  19. By 2005: Managed C++ C# Visual Basic Java Cobol, Fortran, …?

  20. Design for multiple languages C++Give me template specialization C++Can I write class C<T> : T C#Just give me decent collection classes C++And template meta-programming JavaRun-time types please Visual BasicDon’t confuse me! EiffelAll generic types covariant please HaskellRank-n types? Existentials? Kinds? Type classes? MLFunctors are cool! SchemeWhy should I care? COBOLChange my call syntax!?!?

  21. Simplicity => no odd restrictions interface IComparable<T> { int CompareTo(T other); } class Set<T> : IEnumerable<T> where T : IComparable<T>{ private TreeNode<T> root; public static Set<T> empty = new Set<T>(); public void Add(T x) { … } public bool HasMember(T x) { … }}Set<Set<int>> s = new Set<Set<int>>(); Interfaces and superclass can be instantiated Constraints can reference type parameter (“F-bounded polymorphism”) Even statics can use type parameter Type arguments can be value or reference types

  22. Non-goals • C++ style template meta-programmingLeave this to source-language compilers • Higher-order polymorphism, existentialsLet’s get the basics right first!

  23. Compiling polymorphism, as was Two main techniques: • Specialize code for each instantiation • C++ templates, MLton & SML.NET monomorphization • good performance  • code bloat  (though not a problem with modern C++ impls) • Share code for all instantiations • Either use a single representation for all types (ML, Haskell) • Or restrict instantiations to “pointer” types (Java) • no code bloat  • poor performance (extra boxing operations required on primitive values)

  24. Compiling polymorphism in the Common Language Runtime • Polymorphism is built-in to the intermediate language (IL) and the execution engine • CLR performs “just-in-time” type specialization • Code sharing avoids bloat • Performance is (almost) as good as hand-specialized code

  25. Code sharing • Rule: • share field layout and code if type arguments have same representation • Examples: • Representation and code for methods in Set<string> can be also be used for Set<object> (string and object are both 32-bit GC-traced pointers) • Representation and code for Set<long> is different from Set<int> (int uses 32 bits, long uses 64 bits)

  26. Exact run-time types • We want to supportif (x is Set<string>) { ... } else if (x is Set<Component>) { ... } • But representation and code is shared between compatible instantiations e.g. Set<string> and Set<Component> • So there’s a conflict to resolve… • …and we don’t want to add lots of overhead to languages that don’t use run-time types (ML, Haskell)

  27. Object representation in the CLR vtable ptr vtable ptr element type fields no. of elements elements normal object representation:type = vtable pointer array representation:type is inside object

  28. Object representation for generics • Array-style: store the instantiation directly in the object? • extra word (possibly more for multi-parameter types) per object instance • e.g. every list cell in ML or Haskell would use an extra word • Alternative: make vtable copies, store instantiation info in the vtable • extra space (vtable size) per type instantiation • expect no. of instantiations << no. of objects • so we chose this option

  29. Object representation for generics x : Set<string> y : Set<object> vtable ptr vtable ptr fields fields code for Add Add Add code for HasMember HasMember HasMember ToArray ToArray code for ToArray … … string object

  30. What’s in the design? • Type parameterization for all declarations • classes e.g. class Set<T> • interfaces e.g. interface IComparable<T> • structse.g. struct HashBucket<K,D> • methods e.g. static void Reverse<T>(T[] arr) • delegates (“first-class methods”) e.g. delegate void Action<T>(T arg)

  31. Precompilation (ngen) • JIT compilation is flexible, but • can lead to slow startup times • increases working set (must load JIT compiler, code pages can’t be shared between processes) • Instead, we can pre-compile • .NET CLR has “ngen” tool for native generation • IL is compiled to x86 up-front • runtime data structures (vtables etc) are persisted in native image • read-only pages (e.g. code) can be shared between processes • loader now responsible only for “link” step (cross-module fix-ups)

  32. Ngen for generics • For non-generic code, to ngen an assembly: • just compile every class and method in the assembly • perhaps inline a little across assemblies • For generic code: • compile every generic class and method, but at what instantiations? • just reference types? (code is shared) • or some “commonly-used” types? (e.g. int) • we don’t know statically what instantiations will be used • it’s a “separate compilation” problem

  33. Ngen all instantiations • Our approach: • always compile generic code for reference-type instantiations • for value type instantiations, compute the transitive closure of instantiations used by the assembly • compile code for those instantiations not already present in other linked ngen images • leads to code duplication • at load-time, just pick one • has some interesting interactions with app-domain code-sharing policy (see SPACE’04 paper on Don Syme’s home page)

  34. NGen: example MyCollections Client1 Client2 class List<T>class Set<T>…Set<int>… struct Point…List<Point>…Set<int>…List<int>… class Window…List<Window>……List<int>… ngen x86 for List<object> x86 for Set<object> x86 for Set<int> x86 for List<Point>x86 for List<int> x86 for List<int>

  35. NGen: when we can’t • JIT is still required for • instantiations requested through reflection (“late-bound”)e.g. typeof(List<>).BindGenericParameters(typeof(int)) • generic virtual methods • double dispatch, on instantiation and class of object • polymorphic recursion (unbounded number of instantiations)

  36. What’s in the design (2)? Constraints on type parameters • class constraint (“must extend”)e.g. class Grid<T> where T : Control • interface constraints (“must implement”)e.g. class Set<T> where T : IComparable<T> • type parameter constraints (“must subtype”)e.g. class List<T> { void AddList<U>(List<U> items) where U : T } • 3 special cases • Can be instantiated (“new”) • Can be null (“nullable”) • Must be a value type (“struct”)

  37. And What About Perf? • Do generics really provide performance? • It depends on how you ask the question… • And who is asking the question • Or at least why they are really asking the question

  38. MSR Perf Measurements

  39. My Perf Measurements • Note: • First three columns are based on my “natural” implementation of QuickSort(Array). • Second three are based on Andrew Kennedy’s QuickSort(Array, ComparisonOperation)

  40. What’s in the design (3)? • Variance annotations on type parameters • covariant subtypinginterface IEnumerator<+T> { T get_Current(); bool MoveNext(); }so IEnumerator<string> assignable to IEnumerator<object> • contravariant subtypinginterface IComparer<-T> { int Compare(T x, int y); } so IComparer<object> assignable to IComparer<string>

More Related