Knowing .NET

Scott Guthrie just announced IronRuby! Yeehaw!!!!!!

—

Silverlight binding; demoing on Mac

—

Dynamic Language Runtime announced

—

“Shipping later this week” (I’m sure he means shipping a beta / CTP)

—

Uses Ruby naming scheme when programming .NET libraries (weird. Not sure I like that.)

—

“Switch the console into Python mode, Ruby mode, VB mode” (he means something called “Dynamic VB”)

—

www.silverlight.net is the commmunity site

(No sign of DLR / IronRuby / IronPython / Dynamic VB on that site as far as I can see)

—

“Componentize dispatching code, code generation, that sort of thing that compiler vendors do” … namechecks to Hugunin and Lam … we shipped this morning the DLR source code” on Codeplex …

(http://www.codeplex.com/Project/ProjectDirectory.aspx?ProjectSearchText=dynamic%20language%20runtime ? )

Naysawn has announced that the Visual Studio unit testing framework (MSTest) is moving into the Pro SKU of Visual Studio. That’s a good start, but I want to lobby for going the whole way:

Please move the unit testing framework into the .NET framework.

Source: MSTest Moving to VS Pro
Originally published on Wed, 28 Mar 2007 08:35:00 GMT by Brad Wilson

And there was much rejoicing…

Of course, Brad’s right that unit-testing libraries ought to move into the base library, but the VS tools are sophisticated enough to be implemented solely as VS add-ins.

John Lam, whose RubyCLR bridge led to a position in Microsoft’s CLR team, hints that an announcement on his project (my guess, X:Ruby::C#:Java) will be forthcoming. Sadly, he hedges as to whether it will be MIX or PDC. Of course, I’ll be going to PDC, but if there is a major dynamic language announcement at MIX, maybe I’ll have to go to that as well…

Absolute times to calculate a fixed range of the Mandelbrot set:

This isn’t even fair because the non-GPU timings are strictly timings of the calculation loop. The GPU timing is actually derived from my frame-rate.

I’m having some trouble getting my shader to run on my desktop (ATI All-In-Wonder with Radeon X800), but will post that number when I can.

Ah, that’s more like it. This is a graph of duration (in seconds) versus the number of threads during a calculation of a Mandelbrot set using the XNA Framework on the XBox 360 (Neil: The previous graph was normalized speed, as you suspected. For more on labeling the Axis in Office 12, see the next post.)

In order to have the XNA Framework distribute processing, you must explicitly set the “thread affinity.” This must be done within the worker thread (presumably early in the ThreadStart delegate) and, on the XBox 360, you must not use the values 0 or 2, which are reserved. Thus, I use code like this:

struct ThreadWorker

{

    int processorAffinity;

    static int processorAffinityIterator = 0;

    internal ThreadWorker()

    {

        switch (processorAffinityIterator)

        {

            case 0  :

                processorAffinity = 1;

                break;

            case 1 :

                processorAffinity = 3;

                break;

            case 2 :

                processorAffinity = 4;

                break;

            case 3 :

                processorAffinity = 5;

                break;

            default :

                processorAffinity = 1;

                break;

        }

        if (++processorAffinityIterator == 4) { processorAffinityIterator = 0; }

    }

   internal void ThreadRun()

   {

   Thread.CurrentThread.SetProcessorAffinity(processorAffinity);

   ... begin work ...

UPDATE: See this new post It looks like XNA does not distribute processing across the multiple cores of the 360:

This is identical code (a Mandelbrot calculation of a fixed size) running with multiple threads. While my desktop machine speeds up with more threads (peaking at 3), the XBox 360 running XNA runs at almost exactly the same speed.

Incidentally, the graphic shows normalized speeds. The actual performance of the XBox 360 is 1/5 – 1/9 that of my desktop (4.43 seconds as opposed to ~.8 seconds single-threaded or ~.47 with 3 threads).

Sweet. Stay tuned for performance benchmarks, concurrency and GPGPU programming experiments on the 360, and maybe even some games…Maybe even a domain-specific language for writing board games.

Here’s a good pattern to use when you have a domain object that combines non-varying and time-varying data. Perrin’s modified the original pattern to use generics: a good choice. (Why is it a good choice? Because objects that combine these two types of data are usually conceived of in a direct-but-composed way: we don’t think of a Product as changing it’s identity because it is or is not on sale, but we do think of a Product and its normal- or sales-price as a combination of two things. While it’s easily possible to express this type of structure using inheritance, making them parameters to a generic is a batter match with the conceptual model.)

Here’s a challenge (for explicitly typed languages: for those with duck-typing it’s trivial):

Design a Snapshot<T> such that you can query any property P in T for a given time. For instance, if you had Snapshot<PlayStation3> myPlayStation, you could query it’s price using code similar to this form:

Price p = myPlayStation.ValueAt(myDateTime).Price()

Hint: Would the problem be easier (or possible) if you were to use a CTP?

John Lam, whose RubyCLR bridge has been a fascinating and seemingly highly-successful project, is joining Microsoft. Details are vague, but he says he’ll “be working in the CLR team” and “I’m not going to leave the Ruby community” but makes it pretty clear that he’s looking to hand off the RubyCLR codebase to the community (hmmm…I have such copious spare time…).

I’ll be trying to wheedle details out of him, but I still feel that Microsoft will not produce a Ruby but, something at least Java:C#::Ruby:X if not even a little bit more of a Ruby-VB hybrid. Timing-wise let’s say that Microsoft has designed a “more dynamic” language (VB.Nexter, Sapphire [Perl->Ruby->Sapphire]). One could well imagine that they might be in a good position to develop a back-room prototype for PDC2007.

Scott Swigart describes Vista Server Core, a GUI-less version of Vista. While I quite like the idea (not just for resources, but because a purely command-line driven server facilitates a shift towards scripting repetitive tasks), there is a deep irony that this version of Vista does not support the .NET Framework.

So we beat on, boats against the current, borne back ceaselessly into the past.

Update: Brian Brewder observes that no .NET == no PowerShell, which pretty much destroys the “shift towards scripting” concept.