About DirectCompute

After NVidia Cuda, OpenCL we got DirectX’s version (of GPGPU parallelism for numerical calculations) named DirectCompute. All three technologies are very similar and have one goal: to provide some sort of API and shader language for numerical calculations that GPGPU is capable of. And if you use it wisely the performance gains over normal CPU are huge, really huge. Not just that you offload CPU but the calculations due to GPGPU massive multithreading (and multicore) are much faster compared to even the most advanced x64 CPU.

It works like this: you prepare enough data that can be worked on in parallel, send it to GPGPU, wait till GPGPU finished processing the data and fetch the results back to the CPU where your application can use them. You can achieve up to a TFLOP with a graphics card sold today.

I guess this information is enough to see what is all about. For more information on the topic check out  Cuda and OpenCL. I’d suggest to check out the DirectCompute web site but the reality is that I couldn’t find any official (or non-official) page that deals with it (it is the youngest of the three but still that could be more online information, don’t you think). However you might check the DirectCompute PDC 2009 presentation here and a simple tutorial.

Of the three I am most interested in DirectCompute because:

1. Cuda is tied to NVidia GPGPU while OpenCL and DirectCompute aren’t
2. I prefer using DirectX over OpenGL for a simple reason – I did work for a client using DirectX so I am more familiar with it

I have a NVidia silent GeForce 9600 series graphic card (cards from GeForce 8 and up are supported) and the good news is that NVidia has been supporting CUDA for a while and recently introduced support for DirectCompute as well. OpenCL is also supported. I don’t know the current state of support for ATI cards.

There is a potential drawback if you go with DirectCompute though. It is a part of DirectX 11 and will run on Windows 7, Windows 2008 and Vista SP2 (somebody correct me). The problem is if you have an older Windows OS like Windows XP or you want support older Windows. In that case you might consider alternatives.

Goal

The not that good aspect of a young technology such as DirectCompute is lack of samples, documentation and tutorials are almost nonexistent. What’s even worse for a .net developer as I am is apparent lack of managed support. Which turns to be there to some extent through Windows API Code Pack (WACP) managed code wrappers. Note, WACP isn’t very .netish such as Managed DirectX was but it is good enough.

So I tried the managed approach for BasicCompute11 C++ sample (that comes with DirectX SDK) through WACP and here are the steps to make it run. It should give you a good starting point if you are DirectComputing through managed code and even if you are using native code. Hopefully somebody will benefit from my experience.

BasicCompute11 sample is really a simple one. It declares a type holding an int and a float, creates two arrays of those with an incremental value ( {0, 0.0}, {1, 1.1}, {2, 2.2}, ….{8191, 8191.0}) and adds them together to a third array.

I’ll be working on Windows 7 x64 with NVidia GeForce 9600 graphics card but will create a Win32 executable.

Steps

1. Install the latest NVidia graphics drivers. Current version 195.62 works well enough.

2. Install Windows 7 SDK. It is required because WACP uses its include files and libraries.

3. Make sure that Windows 7 SDK version is currently selected. You’ll have to run [Program Files]\Microsoft SDKs\Windows\v7.0\Setup\SDKSetup.exe. Note that I had to run it from command prompt because it didn’t work from UI for some reason.

4. Install DirectX SDK August 2009 SDK.

• If it doesn't exist yet then declare an environment variable DXSDK_DIR that points to [Program Files (x86)]\Microsoft DirectX SDK (August 2009)\ path.
  

5. Install Windows API Code Pack. Or better, copy the source to a folder on your computer. Open those sources and do the following:

• Add $(DXSDK_DIR)Include path to Include folder
  
• And $(DXSDK_DIR)Lib\x86 to libraries
  

After these settings the project should compile. However, there are additional steps, because one of the methods in there is flawed. Let’s correct it.

• Open file Header Files\D3D11\Core\D3D11DeviceContext.h and find method declaration 
  Map(D3DResource^ resource, UInt32 subresource, D3D11::Map mapType, MapFlag mapFlags, MappedSubresource mappedResource);
  (there are no overloads to Map method). Convert it to
  MappedSubresource^ Map(D3DResource^ resource, UInt32 subresource, D3D11::Map mapType, MapFlag mapFlags);
• Open file Source Files\D3D11\Core\D3D11DeviceContext.cpp and find the (same) method definition
  DeviceContext::Map(D3DResource^ resource, UInt32 subresource, D3D11::Map mapType, D3D11::MapFlag mapFlags, MappedSubresource mappedResource)
  Replace the entire method with this code:

  MappedSubresource^ DeviceContext::Map(D3DResource^ resource, UInt32 subresource, 
      D3D11::Map mapType, D3D11::MapFlag mapFlags)
  {
  D3D11_MAPPED_SUBRESOURCE mappedRes;
  CommonUtils::VerifyResult(GetInterface<ID3D11DeviceContext>()->Map(
  resource->GetInterface<ID3D11Resource>(), 
  subresource, 
  static_cast<D3D11_MAP>(mapType), 
  static_cast<UINT>(mapFlags), 
  &mappedRes));
  return gcnew MappedSubresource(mappedRes);
  }

DirectX wrappers we need are now functional. Compile the project and close it.

6. Open DirectX Sample Browser (you’ll find it in Start\All Programs\Microsoft DirectX SDK (August 2009) and install BasicCompute11 sample somewhere on the disk.

7. Open the sample in Visual Studio 2008 and run it. The generated console output should look like this:

Pay attention to the output because if DirectX can’t find an adequate hardware/driver support for DirectCompute it will run the code with a reference shader – using CPU not GPGPU (“No hardware Compute Shader capable device found, trying to create ref device.”) or even won’t run at all.

If the sample did run successfully it means that your environment supports DirectCompute. Good for you.

8. Now try running my test project (attached to this article) that is pure managed C# code. It more or less replicates the original BasicCompute11 sample which is a C++ project. The main differences with the original are two:

• I removed the majority of device capability checking code (you’ll have to have compute shader functional or else…)
• I compile compute shader code (HLSL –> FX) at design time rather at run time. This is required because there are no runtime compilation managed wrappers in WACP because those are part of D3DX which isn’t part of the OS but rather redistributed separately. So you have to rely on FXC compiler (part of DirectX SDK). A note here: I’ve lost quite a lot of time (again!) figuring out why FXC doesn’t find a suitable entry point to my compute shader code when compiling (and errors out). I finally remembered that I’ve stumbled upon this problem quite a long time ago: FXC compiles only ASCII(!!!!!) files. Guys, is this 2009 or 1979? Ben 10 would say. “Oh man.”
  Anyway, the FX code is included with project so you won’t have to compile it again. This time the output should look like this:
  

I didn’t document my rewritten BasicCompute11 project. You can search for comments in the original project.

Conclusion

Compute shaders are incredibly powerful when it comes to numerical calculations. And being able to work with them through managed code is just great. Not a lot of developers will need their power though, but if/when they’ll need them the support is there.

As for final word: I miss documentations, tutorials and samples. Hopefully eventually they’ll come but for now there is a good book on CUDA (remember, the technologies are similar) – the book comes in a PDF format along NVidia CUDA SDK.

Have fun DirectComputing!

DirectComputeManaged.zip (2.05 mb)

Here is my current short list of two companies involved with hardware and/or software sale that I won’t buy from again due to the various reasons.

First is HTC, yes, the one that produces all sort of phones. In fact it massively produces new versions monthly. Does this suggest that they are smart and productive? I’d rather say that they a) don’t know what to produce and thus they throw a lot of different versions on the market and b) they count on customers buying newer and newer versions of their hardware instead of keeping existing ones. The latter is strictly linked to the fact that HTC is very reluctant to fix existing bugs and you pretty much can’t count on upgrading to newer OS even though your device could easily run it. Did I mention that they sometime forget to include drivers, like graphics acceleration? Of course, they kindly suggest to buy a new device if you want hw accelerated graphics because they just won’t provide it for your model for some reason. I am specifically talking about HTC TyTN II aka Kaiser, not a cheap device by any means. A device that is in fact in 75% range of iPhone v1 hardware performances including graphics, if there was a proper driver. Yet due to the missing graphics hardware acceleration and very much outdated WM6.x this device is nowhere near iPhone. People might think that the situation would improve with HTC Android devices but it certainly doesn’t look so. True, HTC is creating attractive models from hardware perspective but the little things like bugs, hardware issues and mostly the company’s arrogant and greedy attitude put them to my blacklist of companies I' won’t buy again from. Warning, I am talking about my experience with HTC and I am not implying that other companies are better or worse.

So, what will be my next phone? I’ve decided to try Android. I like the fact that it is open source and modern. What about the device? Currently I am considering Motorola Milestone because it a) has good hardware (a bit faster CPU wouldn’t hurt though) and b) is a Google reference device meaning no custom Motorola UI put on top of it. Why is this good? Because upgrading to newer Android versions shouldn’t take long and certainly they won’t depend on anybody else but Google (hopefully, the future will tell). I certainly don’t want to depend on companies such as HTC anymore. Pity though Milestone isn’t yet being sold nearby (I am not that keen to pay 50€ (>10% of the device) for postage from Germany to Slovenia) in Europe.

The other one is Kettler, a German fitness equipment manufacturer. What it has to do with hardware or software? Oh, it does. Among other fitness machines they have a rowing machine featuring an onboard “computer” and USB port. The older version of this rower featured a PC application (for a healthy price) that linked to the machine through the USB port and could control and/or register various data – it got total control of the rowing machine. Imagine the possibilities. The slightly newer version of the same rowing machine isn’t compatible anymore with this PC software (which I found only after I’ve bought the machine) but they assured a newer version is on the way. This was years ago. I’ve asked them several times whether it is possible to get at least communication protocol specs so I could create the software I wanted myself. All answer were like: “our policy is not to disclose anything, we won’t give you anything” – you get the idea. But will you ever release an updated PC application? “We might be working on it”. Years after nothing to see. I can only deduce that they don’t care about their customers. They never disclosed this version incompatibility. Again, their hardware is fine, it’s their software and mostly attitude that put them on my blacklist. BTW, is anybody out there willing to reverse engineer the 256KB ROM (Freescale HCS12 CPU) to understand the protocol? I’d try but having no experience it would take me a long time (I imagine a skilled person might understand it quickly). The time I currently don’t have unfortunately.

If I were to buy a rowing machine again I’d buy a Concept2 rower which comes with all sort of free PC applications and even a free SDK – heck, the company even encourages you to write applications. In fact I might switch to it after I sell my Kettler on eBay.

Why am I writing all this? Well, sharing bad experience helps others from falling in the same hole. After all we mostly judge companies by bad experience don’t we? Furthermore exposing such bad practices might make them think twice. So take my writing as you wish but consider yourself warned :-). Also I am not saying that I won’t buy from those companies ever: I might but not before the company policy changes considerably.

That said I am interested in your blacklists as I am sure everybody keeps one. Perhaps we can create a blacklist page.

Check out Reactive Extensions to .NET (Rx). Looks like it includes “a back ported (and unsupported) release of Parallel Extensions for the .NET Framework 3.5 in the form of System.Threading.dll”. So, if you don’t have Visual Studio 2010 beta handy you might check it out and let us know how it goes. While you are there make sure you check out Rx as well as it looks an interesting and useful library once you grasp its concepts.

See the related blog post.

Look at the picture below, it is a DevExpress' XtraTabControl (WinForms) with a single page hosting a normal Button. Both XtraTabControl and Button are set as Dock = Dock.Fill. Somebody (read: my client) considers that there is just too much wasted space around them (annotated with arrows):

There are no properties to modify padding behavior but luckily DevExpress supports skinning and I solved it through the use of slightly modified skin based iMaginary in this case.

Preparation

Fire up SkinEditor (found in All Programs/Developer Express v2009 vol 2/Components/Tools) and create a new skin based on iMaginary out of the box skin. For more info on creating new skins see this help topic. Save the new project and build the skin assembly. Create a new Visual Studio project, reference the skin assembly and code similar to this (substitute SKINPROJECTNAME and SKINNAME with your names):

DevExpress.Skins.SkinManager.Default.RegisterAssembly(typeof(SKINPROJECTNAME).Assembly);!XtraForm f = new XtraForm();
f.LookAndFeel.SkinName = "SKINNAME";
f.LookAndFeel.UseDefaultLookAndFeel = false;XtraTabControl ctl1 = new XtraTabControl();
ctl1.Dock = DockStyle.Fill;XtraTabPage page = new XtraTabPage { Text = "One" };
ctl1.TabPages.Add(page);Button b = new Button { Text = "Dock.Fill" };
b.Dock = DockStyle.Fill;
page.Controls.Add(b);
f.Controls.Add(ctl1);

Now you have a test project that should output the window above.

Step 1 – The drawing of XtraTabControl the border

DevExpress controls use template images that are properly resized for most of the resizable drawing including XtraTabControl’s borders.

Find the TabPane node in the tree view on the right

and you’ll see the border template image:

Note that the shadows are drawn within this template, not programmatically. Red lines are borders that determine what part of the image is copied to provide dynamically size final image. First, close SkinEditor. Then find the template image on the disk ([SKIN PROJECT]/[SKIN NAME]/Tab/TabPane.png) and use on of the paint applications to get ride of the shades (by copy paste the parts without shades) and expand the usable area to get a result like below, reopen SkinEditor and load the skin project (I did move borders to 2,2,2,2 as well – you can drag them with mouse or by setting proper values on the left).

If you run the test application it will show painted borders as expected but the button will remain on the original position regardless of this change. For now only the drawing changed but not the behavior.

We are half way now. Obviously the page content margins have to be adjusted as well.

Step 2 – adjust page content margins

First instinct was to adjust Tab’s parameters of my skin in the SkinEditor, it has to be one of these I thought:

Left and RightContentIndent were the obvious choices.  But no, they have no effect in our case. So I resorted to what every developer does: I looked at the sources of the XtraTabControl. It turns out that the solution is rather simple yet not supported by SkinEditor for some reason. Instead I had to manually modify the skin’s XML definition you’ll find in [SKIN PROJECT]/[SKIN NAME]/skin.xml file.

Open the skin.xml and find the line that contains this content: SkinProduct="Tab" SkinName="[SKIN NAME]". It should look like:

<Skin4 SkinProduct="Tab" SkinName="SKIN NAME">

(don’t ask me why there is a node named Skin4 and others numbered from 1 on). So, within this node find the node named TabPane. Within TabPane node adjust the attributes of ContentMargins node to values you want. I.e. try this:

<ContentMargins Bottom="1" Top="1" Left="1" Right="1" />

This would be a lot more straightforward if ContentMargins were available through SkinEditor’s UI. I hope that SkinEditor will get more treatment in the future as it lacks other features as well.

While trying to compiling nVidia CUDA kernels on my Windows 7 x64 I realized that somehow I didn’t install the Visual Studio 2008 C++ x64 compilers and tools.

So I tried updating Visual Studio by going to Control Panel/Programs And Features bla bla only to get this error dialog showing up:

Huh? I did have the ISO image mounted. Once more Google found Mike Eshva’s solution to the problem: uninstall SP1, add feature and reapply SP1. I am sure I’ve read this solution before but I never needed it. Later on I’ve found a bug report on Microsoft Connect with exact same motivation, the problem and the workaround as well.

The funny thing is that it didn’t work exactly like that for me. I’ve uninstalled SP1 and then I couldn’t get into uninstall/change dialog anymore. Ooops. But I wasn’t too worried because right before the process I’ve made a backup to my trusty Windows Home Server. Just in case. I didn’t need it though. Anyway I’ve reapplied SP1 and then it started working as it should – I was able to add the x64 feature just as it should be. Except for one additional obstacle during add process:

Argh. This one I’ve solved with help from this blog post.

I guess one or more of the updates/hotfixes after SP1 was causing the original problem (and was uninstalled with SP1), which one I’ll never know.

Bottom line

I hope that Visual Studio 2010 will handle better the updates. The way Visual Studio 2008 handles the updates looks like one big mess and it is scary to change anything within updates, service packs and hotfixes.

Today I’ve tried to ILMerge a WinForms application that uses a bunch of DevExpress controls to produce a single executable in response to this thread. Just for testing purposes.

The thing is that ILMerge is a console application that requires a healthy amount of command line parameters. Not wanting to type them like crazy, I’ve opted to use ILMerge action within Final Builder that provides an UI for entering parameters (which are mostly long paths to assemblies involved in merging):

Instead of writing all those paths in command line and figuring out the command line parameters syntax I just clicked few “folder buttons” and navigated through open file dialogs.

The bottom line is that I’ve spent half a minute with Final Builder instead of many minutes in command prompt. The only drawback is that I’ve spent additional minutes writing this post.

Looks like I’ve found another use for Final Builder as well.

If you ever wrote a multithreading application you should understand how hard is to get it right. If you don’t understand it then your application most probably isn’t written correctly.

You’ve written a multithreaded application and now what. How can you test it whether it is written correctly or not. Unit testing won’t be of great help because there are complex currency issues that might manifest in a bug only under certain circumstances. Imagine this piece of code:

class Program{
static int x;
static Random rnd = new Random();
static void Main(string[] args)
{
List<Thread> threads = new List<Thread>();
for (int i = 0; i < 4; i++)
{
Thread t = new Thread(Runner) { IsBackground = true };
t.Start();
threads.Add(t);
}
foreach (Thread t in threads)
{
t.Join();
}
}
static void Runner()
{
for (int i = 0; i < 1000000; i++)
{
Thread.Sleep(rnd.Next(10));
int orig = x;
x += 5;Debug.Assert(x == orig+5);
        }
}
}

I am increasing a shared static variable from multiple threads without any synchronization. Will it work? It might or might not (try it!). It depends on when different threads are accessing the variable x. One thing is for sure, this code isn’t correct and it most probably won’t work and for sure it won’t work always. That is the biggest problem with multithreading – if something works it doesn’t mean that it it is correctly written and that it will work always. More about this later. If you use unit testing to test runner method the test will pass because unit testing doesn’t test multithreading, at least not easily.

So, how does one test such code and scenarios. One way is to use a static analysis tool. The other way is to put a jinx on your application. Once your application is jinxed it will be much more prone to displaying concurrency and other multithreading errors. And that’s exactly what Jinx does. Behind the scenes it makes your application fail more often that it would fail in normal circumstances. I mean that it shows faults in the application (if any) that would otherwise remain hidden and would occur only randomly here and there (you know, your user will find it after 2 minutes of running the application) – it doesn’t fail your application for no reason, it just emphasizes your bugs.

The most interesting aspect of Jinx is its the way it works. Jinx is a sort of hypervisor. You certainly know Hyper-V hypervisor whose task is to run guest operating systems. Jinx’s task is to make a clone of your OS and debugged application within and run multiple versions of it under various conditions. This is done so that any multithreading error is more likely to appear. Just by running more versions of the same application the error is more likely to manifest itself. But Jinx throws all sort of other jinxes to your application as well. That’s the shallow explanation. You’ll find more on official overview page and FAQ page.

So, let’s jinx the code above. Note that if you don’t want to you don’t need any modification of an existing code. Jinx can be set to do its task on any newly run application. However, some fine control is a better way to go. Here are the simple steps for selective jinxing:

1. Reference jinxinterface assembly. It contains a single static JinxInteface class with a bunch of static methods and serves as a communication bridge between application and Jinx.
2. Add jinx.cs file to your project. Again it contains a single static Jinx class that is a wrapper around JinxInteface class mentioned above. Its purpose is mostly to apply Conditional("DEBUG") over methods so they won’t get executed for non-debug version of the application.
3. Call Jinx.RegisterApplication(); method at start of the application. This way you’ll let Jinx know that your application should use some jinxing.
4. Replace Debug.Assert with Jinx.Assert. The only difference with both asserts is that the latter send statistical information to Jinx.

After the changes the code should look like this:

class Program{
static int x;
static Random rnd = new Random();
static void Main(string[] args)
{
Jinx.RegisterApplication();List<Thread> threads = new List<Thread>();
for (int i = 0; i < 4; i++)
{
Thread t = new Thread(Runner) { IsBackground = true };
t.Start();
threads.Add(t);
}
foreach (Thread t in threads)
{
t.Join();
}
}
static void Runner()
{
for (int i = 0; i < 1000000; i++)
{
Thread.Sleep(rnd.Next(10));
int orig = x;
x += 5;Jinx.Assert(x == orig + 5);
}
}
}

Before any analyzing takes place Jinx should be enabled and set – this is a system wide option. There are two ways to open the Jinx console – either through Tool/Jinx Visual Studio menu item or directly from All Programs via start menu. Either way you need Administrator privileges. Enabling is easy, just check Enable Jinx checkbox and that’s it. As per what programs are analyzed I’ll use “Analyze the most recent program I have registered.” option.

You can adjust some strategy settings on Strategy tab, I’ll skip this as it is an advanced option. And you can see the statistics on Status tab. Let’s run the application now. Jinx will kick in and the CPU will get under heavy load and the system might shutter due to Jinx running versions of the application in parallel. But the assert failure pops up almost immediately – the bug was caught for sure. If you run the application without jinxs there error would manifest much more later if at all and note that the test code in question is an extreme example. Here is the status tab page after a couple of errors caught:

The asserts observed counter is increased thanks to Jinx.Assert method call. Jinx analyzer isn’t limited to asserts and it might catch other type of errors as well according to PetraVM guys. Jinx is much more than this simple example.

So far I’ve run few examples like this and Jinx performed well and I think Jinx is a good weapon against multithreading bugs. However there might be a problem for testing. Since Jinx is a hypervisor on its own it won’t get along with other hypervisors such as Hyper-V. In other words forget about running Jinx on guest OS. A dedicated machine is required. Perhaps this issue will change in the future.

Also be careful when experimenting with Jinx as it is in beta phase right now (you can apply for testing over here). Running a beta hypervisor might result in a BSOD and all the consequences from BSOD such as non bootable Windows after. Which happened when I was writing this post. Perhaps this post is jinxed as well :-). Humor aside, I am sure guys behind Jinx will make it rock solid for the RTM. They obviously know very well the hypervisor craft.

Happy jinxing your applications!

I am working on a some sort of file cache system lately and I’ve encountered a bizarre error. When a certain file representing an image had to be deleted it wouldn’t let it – an IOException was thrown stating:

The process cannot access the file '[FILEPATH]' because it is being used by another process.

The odd thing is that I’ve used this file only for retrieve images from and I had no idea why would it be locked. Eventually I’ve traced the lock down to this line:

Image result = Image.FromFile(path);

Would you say that the line above would lock a file? I wouldn’t. But it does for some obscure reason. Thus switching to Image.FromStream did the trick:

using (FileStream stream = File.OpenRead(path))
{
return Image.FromStream(stream);
}

It is more lines but it works as expected.

IMPORTANT UPDATE: The workaround described above only seems to work - it crashes randomly. By reading documentation (who does that anyway? - thanks Dario for the hint ) it states that the stream has to open for the lifetime of the Image. Ouch. So here is the second workaround that works for sure - I copy the data to a MemoryStream and create image from there. It is even more lines but this time it has to work (there is a Stream.CopyTo method in forthcomming .net 4.0).

using (FileStream stream = File.OpenRead(path))
{
    MemoryStream imageDataStream = new MemoryStream(Convert.ToInt32(stream.Length));
    byte[] buffer = new byte[4096];
    int read;
    while ((read = stream.Read(buffer, 0, buffer.Length)) != 0)
    {
        imageDataStream.Write(buffer, 0, read);
    }
    imageDataStream.Position = 0;
    return Image.FromStream(imageDataStream);
}

Check out this post about what’s new in the BCL in .net 4.0. beta 2. As you can see there is a good amount of timesaving functionality.

My favorites are Stream.CopyTo, String.Concat/Join overloads that take IEnumerable<T> (no more casting IList to Array!) and of course Enum.HasFlag which I already implemented it my way.

I wonder though why they created Environment.Is64BitProcess and Is64BitOperatingSystem. At the present time it makes sense but Microsoft is already talking about 128 bit Windows OS. We’ll get, I suppose, a couple of years after a 128 bit Windows is released new properties: Environment.Is128BitProcess and Is128BitOperatingSystem and years after that perhaps 256 bit versions of them.

So, wouldn’t it be easier to have an enum like:

enum Bitness{
16Bit,
32Bit,
64Bit}

And when 128 bit version comes out a new value of 128Bit might be added. So we might have Environment.ProcessBits and Environment.OSBits or something that would return Bitness enum, would be future proof and easier to use than inspecting all IsXXXBitXXX methods.

Or perhaps, if adding a new value to an enum poses some kind of problem, just return an int instead of an enum representing the number of bits.

Both Visual Studio 2010 beta 2 and .net 4.0 beta 2 are available for MSDN subscribers and on Wednesday for everybody. Perhaps an important feature is that a “go live” license is available.

Release has been announced for March 22th next year. I guess RTM will be available before the year’s end for MSDN subscribers – judging from the Visual Studio 2008 timeline.

Here is a bounch of useful beta 2 launch blog posts:

About TFS 2010

Hanselman’s post

Jason Zander’s post

What’s new for the Task Parallel Libary

ScottGu’s post

and of course Somma’s post

Just don’t forget that this is beta 2 release and you should be cautious – installing it in a virtual machine rather then production one is always a good practice when dealing with early builds.