Jonathan Hardwick : .NET

Why we've posted a beta refresh of System Center Capacity Planner

jonathanh — Sun, 30 Oct 2005 19:36:00 GMT

A week ago we updated the public beta of System Center Capacity Planner. This “beta refresh” of SCCP is now dependent on the release candidate of .NET Framework 2.0, instead of being dependent on their beta 2 release.

Shipping this refresh took a lot of effort from the SCCP team, and causes extra confusion for our users. So why did we do it? The answer is that it’s the price of taking a dependence on .NET 2.0 when they were in the middle of their development cycle. Although their beta 2 had a “go live” license (i.e., they considered it good enough for production purposes), the .NET team still wanted to move their customers onto RC and RTM as soon as possible after they were released. So we agreed to replace our original SCCP beta – which requires NET beta 2 – once they had RC bits to give us.

That’s the downside, and it’s pretty much an inevitable one as soon as you take a dependency on any other team or feature: rule #1 for shipping software is to minimize the number of dependencies you take. The upside is that, by taking advantage of the new features in .NET 2.0, we’ve been able to ship better code, and do so more quickly. Overall, we think this is a net win. And we still love managed code :)

Oh, and even though it was “just” a refresh, we managed to sneak in a few new features:

Improved support for modeling VPN connected users
More granular control of Exchange transaction rates
Optional exclusion of a redundant WAN link from load balancing
Improved support for users in branch office
Improvements to reporting
Improvements to the Hardware Editor
Improved online help
Modifications to the user interface text

If you have any questions, please post them here, or on the community forums, and we’ll do our best to answer them!

A community-based marketing experiment - Microsoft gets on board the Cluetrain!

jonathanh — Mon, 08 Aug 2005 18:18:00 GMT

The Visual Studio 2005 evangelists have created a new community marketing experiment: High Five Wikisheets. Microsoft marketing has taken some flak in the past (ahem), but this wiki seems to be pure Cluetrain Manifesto material. Risky, radical, and all about the conversation. I love it :)

I first heard about the idea a couple of weeks ago, when I was looped into a discussion between Craig Neable and the Channel 9 team. Craig and his boss Carter Maslan work every day with developers who are trying to sell their bosses on the benefits of .NET. I figure this normally means a lot of “push” marketing – preparing datasheets and case studies and competitive analyses. Then Carter had the slightly-crazy idea that the developers themselves know why they want Visual Studio 2005, so why not give them the floor? Or, in his own words:

Nowadays, some of the best “Marketing” is happening in a Cluetrain Manifesto style expository conversation taking place at scale in community blogs – 1000s of them. The problem is blogs stink at synthesizing and summarizing those conversations at any given moment. Where can I go for a synopsis of the top reasons to move to VS 2005? Does that synopsis reflect the breadth and depth of the community’s actual project experience How could Marketing datasheets become succinct and accurate reflections of the real-life project experiences of the community?

Craig bounced a few namespace ideas off me, some of which I teased him for unmercifully (sorry Craig!), and then we got down to playing with prototypes. To kick things off, Craig and Carter have added the reasons they think companies will love Visual Studio 2005, but now the High Five Wikisheets are open to developers everywhere. Got a great reason that convinced your boss to switch? They want to hear it. Convinced that Visual Studio 2005 adds no value? They want to hear that too. Spotted a connection between two different scenarios? Refactor the wiki — or just join in the conversation on Channel 9!

Now, I wonder what Rick Segal and Seth Godin think?

Technorati tags: Cluetrain, Marketing, Microsoft, Wikis

A good week for new .NET programming languages

jonathanh — Thu, 16 Jun 2005 08:48:00 GMT

IronPython is a .NET implementation of Python, written by Jim Hugunin. It’s now reached v0.7.6, and has been released on microsoft.com (via Mike Gunderloy). What’s really impressive is that IronPython is faster than Python 2.3.

F# is a .NET implementation of an ML-family language, written by Don Syme. Don describes the goals of F# in the latest EndBracket column for MSDN Magazine:

After five years of guiding generics for the Microsoft .NET Framework into Visual Studio 2005, I've turned my attention to attempting to achieve a synthesis between type-safe, scalable, math-oriented scripting and programming for .NET. I believe the industry needs to do more for scientists and mathematicians, where the demand for this kind of language is great.

And no, he’s not kidding when he said that it’s taken him five years to see generics through from the first academic paper to their industry-wide acceptance in .NET 2.0. I can understand why he now wants to do something smaller! You can grab the latest version of F# from http://research.microsoft.com/research/downloads.

This month’s MSDN magazine also has a great article by Joel Pobar on the cost of reflection in .NET languages. Or at least, it’s great if you worry about things like the performance implications of late-binding vs. early-binding, and whether you’re getting the best benefit out of the MemberInfo cache. If you’re that kind of low-level performance-frobbing bit-twiddling freak, you’ll love this article :) (via Brad Abrams)

Finally, here’s some IronPython and F# to whet your appetites. IronPython first (from TheServerSide.NET):

import sys sys.LoadAssemblyByName("System.Drawing") sys.LoadAssemblyByName("System.Windows.Forms") from System.Windows.Forms import * from System.Drawing import * f = Form(Text="Windows fun with IronPython", HelpButton=True, MinimizeBox=False, MaximizeBox=False) f.FormBorderStyle = FormBorderStyle.FixedDialog f.StartPosition = FormStartPosition.CenterScreen b1 = Button(Text="Say Something", Location=Point(30,30), Size=Size(200,30)) def push(data, event): l = Label(Text="IronPython Lives!", ForeColor=Color.Red) l.Location = Point(30, 50+f.Controls.Count*25) f.Controls.Add(l) b1.Click += push f.Controls.Add(b1) f.ShowDialog()

And here's some F# (from Don's article):

let DistanceFromAverage (a,b,c) = let avg = (a+b+c) / 3.0 in let diff(x) = (avg - x)*(avg - x) in Math.Sqrt(diff(a) + diff(b) + diff(c))

Optimizing managed C# vs. native C++ code

jonathanh — Sat, 21 May 2005 05:40:00 GMT

Raymond Chen (aka "fixed more Windows bugs than you've had hot dinners") and Rico Mariani (aka "Mr .NET Performance") have been running a great series of articles where they write and then optimize the same application in two different languages: native C++ and managed C#. The easiest starting point for the two sets of articles is "Performance Quiz #6 -- Chinese/English Dictionary reader".

There's a lot of good information in both the articles and the reader comments, and if you've got the time they're well worth studying for hints on how to write and benchmark high-performance code. The summary is a compelling argument for .NET:

A line-for-line translation of the original C++ code into C# ran 10 times faster than the C++ code.
It took five different optimizations (one of which introduced a bug) for the C++ code to match the speed of the unaltered C# code.
After Raymond's sixth optimization, his C++ code finally beat the C# code — because the runtime got down to where the 60ms startup overhead of the CLR made a difference!
To accomplish this, Raymond had to:
- Write his own file/io stuff
- Write his own string class
- Write his own allocator
- Write his own international mapping

So yes, C++ code can be faster than C# code — but when you look at all the work Raymond had to go through to achieve that, you have to ask yourself "is it worth it?"

Edit: Jeff Atwood has posted a graph illustrating the diminishing returns of Raymond's optimization efforts.

For all you .NET language developers - Don Syme has started an F# blog

jonathanh — Wed, 05 Jan 2005 21:00:00 GMT

Back when I worked at Microsoft Research in England, Don Syme already had his hands deep in the guts of .NET – he co-authored the original paper on generics for C#, and fought long and hard to get them accepted into v2.0 of the language. That’s no mean feat when you’re in a lab eight time zones away from the people you have to persuade to adopt your work!

He then went one better and built F#, a .NET implemention of the functional programming language ML. The key advance of F# is that it is completely interoperable with other languages – you can write modules in F# and call them from any other .NET language. Now programmers can use functional languages for the core algorithmic problem areas where they really shine, and stick to imperative languages for the uglier bits.

F# has been gradually building steam since then, adding the supporting infrastructure that you’d expect from a .NET language (Visual Studio authoring package, ASP.NET compatibility, …) and the cool features you’d expect from a programming language researcher (dynamic type test patterns, mutually dependent reactive values, …). Now it seems ready to take center-stage: Don has started a blog about F#, and his first post announces the preview release of F# version 1.0.

FlexWiki released to the world!

jonathanh — Tue, 28 Sep 2004 05:13:00 GMT

If you're looking for a great Wiki implementation for ASP.NET, with a good user base and a whole lot of neat features to build on, look no more. David Ornstein has jumped through all the legal hoops, dotted all the i's, crossed all the t's, and has finally been allowed to release his FlexWiki software as shared source. This joins the previous WiX and WTL projects that have moved from Microsoft to SourceForge, for all you journalists keeping track :-)

I've been a happy user of David's previous versions of FlexWiki, both internally and on Channel 9, and now there's even more cool features to look forward to - like WikiTalk:

WikiTalk enables content contributors to access .NET framework objects for dynamic content while working within the traditional Wiki environment and it allows .NET developers to easily expose rich dynamic functionality to writers of Wiki content

Anyone who's remotely interested in wikis or collaborative software should check it out - or come back in a month or two after the community's had a chance to bash it around a bit and create even more wonderful things from it. Big, big thanks to David for hanging in there and making this happen!

Debugging SP2 on the Tablet PC - managed code, tabtip.exe, and procexp

jonathanh — Mon, 30 Aug 2004 09:26:00 GMT

If you've got a Tablet PC and you're running SP2 (and you should be!) you might have noticed a couple of processes hanging around called TabTip.exe and TCServer.exe. And right after noticing them, you probably wondered why they seemed to be taking up so much memory.

Luckily, autoruns is not the only cool tool from those fine folks at Sysinternals. They've also produced the must-have procexp: it's a better task manager than Task Manager, and is great for these kinds of "what the heck is that process doing" moments. In particular, you can tell procexp to use highlighting to call attention to services, jobs, your own processes, or (as in this case) .NET processes:

Yup, that's right, TCServer and TabTip are both written in managed code - after all, the Tablet PC edition of Windows XP was the first to ship with the .NET CLR, so why not use it? :-) Now we can use another neat feature of procexp: right-click on the TabTip process, bring up its property window, and scroll across to the .NET tab. Managed processes define many counters to keep track of their own performance, and procexp lets you see them all. Here are some of the .NET memory counters for that process:

Now we can see why TabTip seems to be taking up so much memory: even though it's got just 0.5 MB of heap data and 1.5 MB of total data, the CLR has reserved 32 MB of virtual memory for it, "just in case". For users accustomed to unmanaged apps that do their own memory management, this "greedy" memory behavior of the CLR can come as a surprise, but for garbage-collected applications it makes sense. After all, if the machine has sufficient memory, why bother spending the time to collect objects that are no longer used?

As the Windows world moves towards .NET, we'll probably have to spend a lot more time explaining this to customers. In the meantime, procexp is a great tool for looking into the guts of your .NET applications.

Update: AT caught a mistake, now fixed. Also, this diagram from Rico Mariani's excellent introductory article on "Garbage Collector Basics and Performance Hints" shows the difference between allocated, committed, and reserved space very nicely:

Welcome to Jim Hugunin!

jonathanh — Sat, 14 Aug 2004 08:01:00 GMT

Jim Hugunin of IronPython fame (and new Microsoft employee) now has a home on blogs.msdn.com. Check out his first post on Dynamic Languages and the Common Language Runtime. Welcome to the community, Jim!

Preview release of Wintellect's PowerCollections for .NET

jonathanh — Thu, 05 Aug 2004 17:48:00 GMT

Good news in my inbox from the folks at Wintellect:

This month, Wintellect announces the availability of a preview release of its new open source collection class library for .NET 2.0 called Power Collections .NET.
...
Wintellect and Microsoft are co-sponsoring the development effort but ultimately the code will belong to the development community. We urge developers to input their ideas, suggestions and review the classes as they are made available.
...
Of course, the big advantage of .NET 2.0 collections is that they will be type safe and avoid boxing via the use of generics. We’re not going to re-implement collections provided in the Base Class Library (known as the BCL). Anything beyond the BCL that will be readily required (or that the community can make a good argument for), we are going to implement in Power Collections. A starting set will be ordered and unordered Set, Bag, Dictionary (unique and duplicate keyed versions), Double-ended Queue, and Priority Queue. We’ll be adding some utility types, like Pair and Triple and some built-in algorithms. You can review the current version of the specification at http://www.wintellect.com/powercollections/spec.aspx

You can find out more about PowerCollections at Peter Golde's blog.

Update: Brad Abrams points to Peter Sestoft's C5 project, which “is much more complete and is a parallel library to System.Collections.Generic rather than … a natural extension of the BCL library”. Choices are good!

IronPython for .NET released - and it's faster than Python-2.3

jonathanh — Thu, 29 Jul 2004 18:05:00 GMT

Some very cool news from Jim Hugunin about IronPython, his port of Python to .NET:

He's released it under the CPL
It's up to 1.7x faster than Python-2.3 on the pystone benchmark
He's joining the Microsoft CLR team to push for more support for dynamic languages!

To quote the IronPython web page: “My plan was to do a little work and then write a short pithy article called "Why .NET is a terrible platform for dynamic languages". My plans changed when I found the CLR to be an excellent target for the highly dynamic Python language.”

(via Miguel de Icaza and Frank Prengel)

Updates:

From Edd Dumbill's blog: in Jim's talk he showed that IronPython is 4% slower than Python-2.3 using the more realistic parrotbench benchmark.
The slides are now online at oreillynet with more performance figures - IronPython only loses out to Python 2.3 when throwing exceptions. The other good news is that Jim will keep developing it up to v1.0.