//build – Future Directions of C#

Anders Hejlsberg talk at build was as expected very good, my notes and thoughts:

What’s new in C# 5.0:

• Windows Runtime Support
• Asynchrony (async / await keywords)
• Caller Info attributes

Asynchrony Programming:

• Clearly there are lots of scenarios where async execution of methods is desirable, in the context of WinRT implementing polished Metro style apps that don’t block the UI requires work to be done off the UI thread, just as it does in any GUI apps. Of course UI scenarios are not the only ones that require async work!
• Apparently 10 to 15% of the WinRT API’s are asynchronous so clearly MS has thought these through in the context of making it easy to build responsive UI’s
• The async programming models vary across languages, for example: 
  • WinRT (C++): IAsyncOperation<T>
  • .NET: Task<T>
  • Javascript: Promisses
• So, when writing C# libraries to be exposed for WinRT Task’s need to be converted to / from IAsyncOperation’s, the platform provides helpers to do this conversion

Caller Info attributes:

• Not in developer preview, but will be in the final bits
• Anyone whose done any C++ will probably have used the __FILE__ and __LINE__ macros, caller info attributes can be used for the scenarios where these macros would have been used
• C# 5.0 introduces 3 new caller info attributes:
  • CallerFilePath
  • CallerLineNumber
  • CallerMemberName
• At runtime the values get substituted in, these are especially useful for tracing/logging scenarios

Project Roslyn: ‘Compiler as a Service’

• No ship vehicle / date set yet, but CPT will be release in ~4 weeks
• The purpose of Roslyn is to opening up the compiler, making the compilers information available
  • Meta-programming
  • DSL Embedding
  • Refactoring
  • etc
• The compiler APIs exposed broadly map onto the compiler pipeline:
  • Syntax Tree API (Parser)
  • Symbol API (Symbols, Metadata Import)
  • Binding and Flow Analysis APIs (Binder)
  • Emit API (IL Emitter)
• Roslyn ships with a C# Interactive Window in VS – this will be included in CTP, and allows code to be dynamically created and executed in a similar manner to the F# interactive window, which is a very powerful exploration tool
• Anders did a great demo to show off some of the potential power of Roslyn where he copied C# code and pasted it into a VB project – the code was converted to VB and pasted, likewise he then round tripped it and copied VB code and pasted it as C#

//build–WinRT internals

Matt Merrys’ session on the internals of WinRT was interesting and worth watching if you’re interested in understanding WinRT at a deeper level, at the same time it was a little thought provoking in terms of why some of the decisions were made and what the implications are. Whilst you don’t need to understand what’s going on under the hood to write a Metro Style app, its interesting to know and will likely be helpful to understand when things go wrong / debugging.

WinRT is implemented using a modified version of COM, it introduces the IInspectable interface which all WinRT objects implement, the interface derives from IUnknown adding the following methods:

• GetIids() – returns the interfaces that the object supports, in classic COM you needed to know what interface you wanted to QI for
• GetRuntimeClassName() – returns the type of the object, this is used by Javascript to get the fully qualified name of the WinRT class
• TrustLevel() – returns the trust level of the WinRT object

Activation of WinRT objects is very similar to DCOM activation and happens via RPCSS, apps can be in-proc or out of proc (server), which are hosted by wwahost.exe, sound familiar?! Wwahost.exe is the app container, which is effectively a sandbox for the application with a security context. Apps can run in single threaded or multithreaded apartments – though its not clear how that is controlled.

Since activation is performed in a DCOM like manner, meta-data describing where the binaries are located for a given app type is required by the run-time, Microsoft chose to put this in the registry ala COM style. The registry entries are written at deployment time, when running through the VS debugger this happens when you run up an app. Deployment effectively involves running the manifest through the deployment engine which writes entries into the ‘Extension Catalogue’ and ‘Class Catalogue’.

The model is interesting in that in many ways it does perhaps feel like a bit of a move backwards after being immersed in .NET for a number of years now, I say that having been a C++/COM developer for a number of years and at the time thinking COM was the best thing since sliced bread, but the world has moved on. Whilst to a large extent much of this doesn’t effect the apps that are written, there are some implications. Error handling may be less rich, lets face it HRESULT’s are not the best way of passing back error information to the caller, especially when all you get is an E_FAIL. The use of the registry is not one I’m a fan of at all, I personally favour XCopy deployment where possible which is more frictionless approach and less error prone whilst making patching easier. The registry has been a source of pain to me over the years. All calls into the WinRT from managed languages will be via .NET introp which of course doesn’t come for free, though the API does look for the most part like a .NET API when consumed from managed code.

WinRT looks like a rich set of API’s that should enable some great apps to be written. The cross language binding for C++, .NET, Javascript is a good move, though in reality apps written in any of these will need to be ported in order to run them on other platforms such as iPad, it won’t just be a re-compile. The interop performance hit for managed code apps should not be noticeable in the big scheme of things assuming that the WinRT API’s are all ‘chunky’ or async which they appear to be with an initial look.

The bottom line is that the success of the platform will be defined by the apps that are built for it.

//build – F# 3.0 for Information Rich Programming

Don Syme presented a session on F# 3.0, which can be viewed here.

In the context of typical n-tier architectures, the focus of F# 3.0 compared to 2.0 and other languages is:

• Presentation, publication, experience – C#, VB, HTML5, Javascript
• Transformations, analysis, algorithms, parallel – Core F# 2.0 scenarios
• Data Services, Information Access – focus for F# 3.0

So the big focus for 3.0 is to provide support for information rich programming, or to put it another way, provide language support to support large data sets.

• Statically typed languages generally degrade as the variation in data types grows large
• e.g. strongly typed class library for all the chemical elements vs strongly typed class library for every entity in Wikipedia, update in real time as new types are added
• F# 3.0 introduces Type Providers – which are compiler/IDE plug-in, provides library on demand, gives intelisense for information spaces
• Type providers appear to use code generation behind the scenes
• Since Type providers are plug-ins you can write your own

Additionally, 3.0 adds support for

• LINQ queries added
• Improved intellisense
• auto-properties (similarly to C# and VB)
• Standard SI units of measure provided in F# core library
• Leverages many .NET and VS improvements

I can see the new type provider functionality being particularly powerful for exploratory data mining of large data sets. Also, for rapidly developing the data access layer for regular .NET apps since F# libraries can of course be referenced from any .NET app.

//build – is now the time to dust off my C++?

There’s lots of sessions at build on C++. This is kind of interesting, for a long time C++ has been slipping into the background whilst the .NET languages have taken all the limelight and the lions share of investment.

Given that WinRT is developed in C++, it seems pretty apparent that the level of interop for .NET Metro style apps will be greatly increased, the performance implication of this is not clear yet.

The key notes at build made several references to the fact that calls to the WinRT are simply vtable lookups, clearly whilst this is the case for C++ apps (well almost, from memory there is an indirection when using COM in order to get to the vtable) it is not the case for managed apps, you will end up with more instructions (due to the level of interop).

Regardless of any performance hit, managed languages undeniably offer greater productivity and the performance hit in most scenarios will not warrant the need to write the app in C++. But, if you want to squeeze the most performance out of your WinRT app it will need to be developed in C++.

//build – Visual Studio 11, XAML

One of the areas of investment for VS 2011 is around the support for XAML:

• Single XAML designer for C#, C++ and VB, the previous version never really felt like it was finished, an initial look at the VS11 it looks much improved
• The core authoring features of the Blend XAML editor have been integrated into Visual Studio 11, this doesn’t include the complete toolset such as the story board editor, but clearly makes for a more useful editor
• Hiding of XAML elements easy via the document outline
• Re-parenting of elements can be easily done in the document outline view
• Colour picker added, which even works for gradients
• Zoom (mouse wheel with mouse over centre of zoom position) and pan (space bar and left mouse)
• There are some XAML changes for the Win8 release (compared to .NET 4.0), its closest to Silverlight
• Support through the designer to navigate to bound data
• New data binding dialog
• Unfortunately there doesn’t appear to be support yet for binding commands when using MVVM, the toolset only appears to support setting an event handler in the code behind
• The VS preview includes a patch for the designer to fix an issue with the mouse not releasing selection

//build – Windows 8, WinRT thoughts …

Microsoft have been showing off Windows 8 at build which represents some big changes in the user experience of the platform, the shift to ‘Metro style’ apps is interesting and will clearly help target the array of new and emerging devices, particularly those that are ‘touch enabled’.

• The mixed desktop experience in Windows 8 (Metro style and Win7 like desktop) is clearly something that is missing from devices such as iPad which are touch first, for example running GUI’s with dense functionality such as Visual Studio, Visio, PaintShop etc would be challenging to say the least from a touch interface.
• I live the the live tiles, of course the depend on the app’s implementaiton, but provide a great summary view on the app and they do make the iPad feel a little dated (though clearly its very polished in comparison to the developer preview of Windows 8)
• The transition between Metro style and the desktop does feel a little odd, perhaps I just need a little time to used to it, I’m sure there are going to be plenty of changes before it RTM’s.

Playing with the developer preview of Windows 8 on the Samsung slate that Microsoft gave us at build (thanks Microsoft!) its clear its still a little rough around the edges which is to be expected, but it does give a good feel for how its going to shape up.

Microsoft are paying very close attention to the fundamentals of Windows 8 which is great to hear, the working set is kept lower as is the residual CPU utilisation by suspending inactive Metro style processes.

The Windows Runtime or WinRT, is being introduced in Windows 8 which will be used to write ‘Metro style’ applications, its written in C++ and targets C++, .NET and Javascript clients. Interestingly the WinRT libraries whilst C++, export CLR meta data using the same format as .NET (all be it slightly modified), so, ILDASM can be used on them though they won’t have any IL in the implementations. Win32 will live on of course, but WinRT exposes a rich object oriented API surface covering much of the functionality where previously you had to pinvoke Win32 API’s. Its also nice to XAML as the target GUI technology for Windows 8, though this is not WPF as far as I understand. It’s not clear to me yet what this means for WPF in general.

More Disruptor Links…

Martin Fowler has done a great write up on the LMAX Disruptor pattern here, abstract:

“LMAX is a new retail financial trading platform. As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread. The Business Logic Processor runs entirely in-memory using event sourcing. The Business Logic Processor is surrounded by Disruptors – a concurrency component that implements a network of queues that operate without needing locks. During the design process the team concluded that recent directions in high-performance concurrency models using queues are fundamentally at odds with modern CPU design”

The LMAX team has an aggregate blog feed here with some interesting and related posts. There’s a couple of efforts underway to port the disruptor to .NET, though I’ve not found any with perf close to that of LMAX’s implementation.

SQL Server: Diagnosing and Resolving Latch & Spinlock Contention …

The SQLCAT team have released two very good white papers:

Diagnosing and Resolving Spinlock Contention on SQL Server

Diagnosing and Resolving Latch Contention on SQL Server

Rx 1.o is Released

Rx has been released officially, I’ve been using in a production environment for 6+ months and very happy with it. On the client side we’ve implemented the Event Aggregator pattern using Rx – effectively replacing the Prism Event Aggregator with half a dozen lines of code! On the server side, I’ve been experimenting using it to do effectively do complex event processing.

Channel 9 has a bunch of workshops which are worth watching here.

LMAX–’Disruptor’ Framework Open Sourced

Nice to see LMAX has open sourced their general purpose disruptor framework which may be used for exchanging data across concurrent threads, it’s an elegant solution which essentially uses a ring buffer, care around cache alignment, batching and minimising thread locking. LMAX use the disruptor in their order matching engine, their real-time risk management, their in-memory transaction processing system. The white paper explaining the details may be found here. It would be nice to see a .NET port of it!