Jeffrey Richter's Blog

Yahoo Group Set-up for Power Threading Library

JeffreyR — Thu, 26 Jun 2008 07:21:00 GMT

I have set up a Yahoo group for people interested in using my Power Threading Library. Currently, the group is public so anyone can join. I am the moderator of the group and so I can answer questions, offer comments/suggestions on the library's use, and address and bugs or feature requests. I will also make new version announcements via the group as well.

Here is the group information:

Library Link: http://wintellect.com/PowerThreading.aspx
Group link: http://tech.groups.yahoo.com/group/PowerThreading/

Post message: PowerThreading@yahoogroups.com
Subscribe: PowerThreading-subscribe@yahoogroups.com
Unsubscribe: PowerThreading-unsubscribe@yahoogroups.com

I look forward to meeting all of you in the group.

An interview with me about The Performance of Everyday Things

JeffreyR — Thu, 26 Jun 2008 03:15:00 GMT

At the April 2008 Devscovery (http://www.Devscovery.com) event in New York, I recently did a new talk entitled "The Performance of Everyday Things". The talk is about the performance of using everyday constructs in .NET/C# such as method calls, arrays, loops, garbage collection, and much more. I will be repeating this popular talk at the Redmond, WA Devscovery event in August 2008.

After the talk April presentation, I did a small interview related to this topic. The interview can be found here: http://getpixel8ed.com/shows/everything

More about Windows SideShow

JeffreyR — Thu, 26 Jun 2008 03:13:00 GMT

In addition to releasing the .NET Windows SideShow API that I created, the Windows SideShow team has also just released the Windows SideShow for Windows Mobile Developer Preview:

http://www.microsoft.com/downloads/details.aspx?FamilyID=79f19684-f862-4e02-a2b0-0003b4565f34&displaylang=en

Install Instructions: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3432560&SiteID=1

In addition, the Windows SideShow team has announced in conjunction with nVidia a contest for the best SideShow gadgets produced in the next month or so; prizes are trips to nVidia’s nVision conference and a SideShow-enabled Dell XPS 420. For more info, see this web site: http://www.nzone.com/object/nzone_prefacecontest_home.html

Power Threading Library (AsyncEnumerator & SyncGate), .NET Rocks! and SideShow

JeffreyR — Wed, 28 May 2008 04:29:00 GMT

Recently, I have been updating my Power Threading Library by adding some new features, fixing some minor bugs, and improving the documentation and sample apps to demonstrate its features. I am particulary proud of my AsyncEnumerator class which allows you to write asynchronous code using a synchronous programming model. With my AsyncEnumerator, you can, with minimum effort, convert any existing synchronous code into asynchronous code which scales extremely well while also increasing your application's responsiveness. For more information about my AsyncEnumerator, please see my Concurrent Affairs columns in MSDN magazine:
http://msdn.microsoft.com/en-us/magazine/cc163323.aspx
http://msdn.microsoft.com/en-us/magazine/cc546608.aspx

And, if code that uses my AsyncEnumerator class needs to synchronize access to some shared data, then I also offer my SyncGate class. This class works with the AsyncEnumerator class to easily write code that accesses shared data without blocking any threads. Again, this increases scalabilty and responsiveness of any application or service. My SyncGate class is derived from my ReaderWriterGate class which you can read more about in this Concurrent Affairs column:
http://msdn.microsoft.com/en-us/magazine/cc163532.aspx

There are several groups at Microsoft that are using my AsyncEnumerator internally. And, Wintellect has several other customers that are also using it very sucessfully. My Power Threading Library is free and if you decide to use it, I'd love to hear from you. Just add a comment to this blog entry (or e-mail me) telling me about your experience with it.

On another note, I recently recorded a session on .NET Rocks! about the future of hardware. Check it out here: http://www.dotnetrocks.com/default.aspx?showNum=343

And, finally, the managed SideShow library that I created for Microsoft (over a year ago) has finally shipped! This library makes it very easy for .NET developers to create SideShow gadgets that run on Windows Vista. You can download the SDK from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=42f2f862-9987-406c-92a3-6523cf0eb3b3&displaylang=en. The SDK installs the runtime and development components that are required to build and run gadgets for Windows SideShow in Managed Code using the .NET Framework. Windows SideShow Project templates and Documentation are integrated with Visual Studio to give developers the optimal coding experience.

The Runtime package (downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyID=ca8e9272-68e8-4c0c-a239-560c21b66fca&displaylang=en) is targeted for end users. It installs the runtime components that are required to run gadgets for Windows SideShow.

Microsoft is going to start promoting the use of the managed API at TechEd in June 2008 (next month).

eBooks

JeffreyR — Fri, 14 Mar 2008 16:35:00 GMT

Many readers have asked me if an electronic version of my book is available. Unfortunately, the answer is no and there are no plans to make one available. Some older versions of my book were available in electronic form but Microsoft Press and I discovered that many people took the file and posted it on the web. Some people even sold the files which they clearly had no right to do. So, we decided to stop offerring my books in electronic form. It is sad that a few bad apples spoil the bunch.

Windows via C/C++ Table of Contents

JeffreyR — Fri, 14 Mar 2008 16:27:00 GMT

Some (potential) readers have asked me to post the complete table of contents for my new Windows via C/C++ book. Here it is:

Part I Required Reading
1 Error Handling
2 Working with Characters and Strings
3 Kernel Objects

Part II Getting Work Done
4 Processes
5 Jobs
6 Thread Basics
7 Thread Scheduling, Priorities, and Affinities
8 Thread Synchronization in User Mode
9 Thread Synchronization with Kernel Objects
10 Synchronous and Asynchronous Device I/O
11 The Windows Thread Pool
12 Fibers

Part III Memory Management
13 Windows Memory Architecture
14 Exploring Virtual Memory
15 Using Virtual Memory in Your Own Applications
16 A Thread’s Stack
17 Memory-Mapped Files
18 Heaps

Part IV Dynamic-Link Libraries
19 DLL Basics
20 DLL Advanced Techniques
21 Thread-Local Storage
22 DLL Injection and API Hooking

Part V Structured Exception Handling
23 Termination Handlers
24 Exception Handlers and Software Exceptions
25 Unhandled Exceptions, Vectored Exception Handling, and C++ Exceptions
26 Error Reporting and Application Recovery

Part VI Appendixes
A The Build Environment
B Message Crackers, Child Control Macros, and API Macros

CLR via C# will NOT be updated for .NET 3.5

JeffreyR — Mon, 18 Feb 2008 11:08:00 GMT

I get a lot of e-mails asking me if I will be updating my CLR via C# book for .NET 3.5. This blog entry will asnwer this question.

Here is the short answer: NO, I am not updating the book.

Here is the long answer: My CLR via C# book was last updated for .NET 2.0 and I have no intention of updating the book for .NET 3.0 or .NET 3.5. The reason is because my book is really about the CLR and .NET 3.0 and 3.5 still run on top of CLR 2.0.

.NET 3.0 and 3.5 is really CLR 2.0 plus some new DLLs that contain new class libraries for WPF, WCF, WF, Addin support and Linq support. My book has never covered any ancillary class libraries; it has always focused on the CLR itself and the small subset of class library types that talk directly to the runtime engine.

In addition, .NET 3.0 shipped with C# 2.0 and so no changes were made to the C# language/compiler either. Of course, .NET 3.5 does ship with C# 3.0 which does offer many new features (automatically-implemented properties, implicitly typed local variables, extension methods, lambda expressions, object initializers, anonymous types, implicitly typed arrays, partial methods, query expressions, and expression tress). However, all of these features are just compiler syntactic sugar to make syntax easier for programmers. Many of these features are very simple to understand and grasp so I feel that it is not worth updating my book just to cover the new syntax offered by C# to accomplish things you already could do.

While many of the C# 3.0 features are needed to fully leverage the various set of LINQ technologies (Linq to Object, Linq to XML, Linq to Sql, Linq to DataSet, and Linq to Entities). And, while I will address the new C# language features in some future edition of my book (to coincide with the release of a new CLR version), I will never cover LINQ itself; just the architecture that makes LINQ possible.

Also, I just recently completed updating my Windows book (Windows via C/C++, 5th Edition, Microsoft Press) for Windows Vista and Windows Server 2008.

Book Update

JeffreyR — Sat, 16 Jun 2007 02:28:00 GMT

First, the bad news: A while ago, Microsoft Press and I bantered around the idea of producing a version of my "CLR via C#" book targeted towards C++/CLI users. The book was going to be titled "CLR via C++/CLI" (catchy title, eh?). As I am not a C++/CLI expert,we thought we'd find another author for me to work with to produce the book. Unfortunatel, we were unable to find an author and this book project is officially dead.

Now, the good news: My last Win32 book came out around 2000. Several years ago, Microsoft Press declared the book out-of-print which made it near impossible for anyone to fnd. Well, I am revising the book wih a co-author. The book will be updated for Windows Vista/Server 2008 and the book should be out by the end of 2007. The tentative title is "Windows via C++, 5th Edition"

Windows SideShow .NET Framework Components 1.0 (Beta)

JeffreyR — Fri, 19 Jan 2007 04:03:56 GMT

Well, I'm very pleased to announce that the "Windows SideShow .NET Framework Components 1.0 (Beta)" is avialable as of today (January 18, 2007).

You can download it from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=06FA2ACE-A42D-4117-821C-BCE80786F1C4&displaylang=en

This is the managed API that I personally implemented for Microsoft to make it easy for managed developers to write SideShow gadget applications for Windows Vista.

I wrote about SideShow and this API in the January 2007 issue of MSDN Magazine. The article can be found here: http://msdn.microsoft.com/msdnmag/issues/07/01/SideShow/default.aspx

My API is being used to help produce Media Center remote controls such as these:

http://www.cepro.com/products/press/16727.html

http://www.engadget.com/2006/12/21/ricavisions-vista-mce-sideshow-remote-does-bluetooth-at-100-met/

http://www.engadget.com/2007/01/09/hands-on-with-a-bunch-of-sideshow-remotes/

Jeffrey Richter Update

JeffreyR — Wed, 18 Oct 2006 04:40:22 GMT

Hi all,

I have been silent on the blog as usual but thought I'd add an entry today bring you up-to-date on my activities.

I have been extremely busy. Wintellect has gotten some big deals lately which has had me travelling and teaching my .NET Framework class and my new Building Responsive, Reliable, and Scalable Applications and Components class (AKA my Threading class).

In between all this work, I have been reseaching new Windows Vista features that affect threading such as I/O cancellation, wait chain traversal, logical processor information, I/O priorities, transactional file system and registry, and more. In fact, I've added support for a lot of this stuff in my Power Threading library already so that managed developers can use a lot of this stuff when running on Vista. I also plan to write about this stuff in an upcoming Concurrent Affairs column in MSDN Magazine.

Also, Windows Vista has a new feature called SideShow and Microsoft contracted me to produce the managed interface to this new feature. After Vista ships, Microsoft will make the Microsoft.SideShow.dll (which was created by me) available either via Windows Update and/or in the Vista SDK. I explain how to use this new Vista feature and my library in an upcoming MSDN Magazine article (I think the article comes out in the January 2007 issue).

I really like the new SideShow feature and expect to be doing more work with Microsoft to help bring this feature more into mainstream usage.

Accessing Power Collections

JeffreyR — Wed, 18 Oct 2006 04:31:17 GMT

The Power Collections Library on http://Wintellect.com no longer requires that you register with Wintellect.

As of yesterday, you can simply download the file and start using the Power Collections immediately.

New book, new course, new magazine column, new consulting gig, new technologies, and a new vacation

JeffreyR — Fri, 17 Feb 2006 12:20:00 GMT

Well, it has been a long since I last blogged and I've been incredibly busy the past year. I thought I'd share with you some of the things I've done and some of the things I'll be doing.

First, my new book is finished and should be shipping to customers within a week or so. I just got 2 advanced copies of it earlier this week. I think this is my best book ever and I'm incredibly proud of it. This book is the 2nd edition of my “Applied Microsoft .NET Framework Programming” book. I changed the title to “CLR via C#” as the book really focuses on the CLR from the perspective of the C# programmer. You can find it here: http://www.amazon.com/gp/product/0735621632/sr=8-1/qid=1140158045/ref=pd_bbs_1/104-9334151-2570318?%5Fencoding=UTF8http://www.amazon.com/gp/product/0735621632/sr=8-1/qid=1140158045/ref=pd_bbs_1/104-9334151-2570318?%5Fencoding=UTF8. This edition is pretty much a re-write from the first edition. I added a lot of content related to best practices, design guidelines, and versioning. And, of course, there is coverage of new CLR/C# 2.0 features such as generics, anonymous methods, friend assemblies, nullable types, etc. I also added 2 new chapters on asynchronous programming and thread synchronization.

There is a chance that we will produce a “CLR via C++/CLI” version of the book; I'll know for sure in a few months. There will not be a VB version of the book as it has not proven to be cost effective. The source code for all the book’s code samples will be available on the Wintellect web site in mid- to late-March.

Second, I have been busy doing a lot of thread-related work. I am producing a course tentatively entitled “Effective use of .NET Threading in a Multi-Core Processor World.” I have noticed a big increase in developers focusing on how to take advantage of multi-core CPUs. In fact, this is why I now write the Concurrent Affairs column for MSDN magazine. Threading, synchronization, asynchronous operations, reliability, application responsiveness, and scalability have always been pet interests of mine for many years – my Win32 books had 5 chapters on the subject and I added 2 chapters on the subject to my new .NET book. I just love this stuff. I first start teaching this course at Microsoft in early March. If you’re interested in having me teach this course to you and your company, please contact our sales department.

Third, I like threading so much that I’ve started doing some contract work at Microsoft on a project of theirs called the Concurrency and Coordination Runtime (CCR). I’ll be writing about this soon in my MSDN Concurrent Affairs column. Until then, you can get a sneak preview of it by looking at a channel 9 video: http://channel9.msdn.com/Showpost.aspx?postid=143582. This video will give a sense of it but don’t get too into the syntax yet because we’re changing the programming model significantly right now.

Fourth, I have been polishing up my .NET Power Threading library. This library has many useful classes in it for people who want to start taking advantage of threading stuff. The library has many thread synchronization locks (and diagnostic classes) that I wrote myself that have incredibly high performance. There is also my own thread pool and a set of asynchronous programming model classes that perform significantly faster than the CLR’s BeginInvoke stuff. Working on my course had caused me to really polish things up to the point where the code is commercial quality. I will be offering the library on the Wintellect web site some time in mid- to late-March. The library will be royalty free – please see the EULA that comes with the library for some minor restrictions on its use.

Fifth, I have also been playing around a lot with C# 3.0 features and will be doing the Devscovery keynote on C# 3.0. If you’d like to see it, please register at http://Devscovery.com/. I’ll also be presenting a bunch of talks on threading and reliability.

Sixth, I’ve also been spending a good bit of time on Windows Communication Foundation stuff. I’ve been reviewing and contributing a bit to our resident Indigo expert, Justin Smith, as he produces our Indigo course and he is also writing a book on Indigo to be published by Microsoft Press.

Seventh, I’ve also been spending a lot of time playing with Windows Vista. I run it in a VPC right now but I expect to install it and use it daily once beta 2 becomes available.

Anyway, there seems to be no shortage of technology-related things to play with and keep me busy. Now that the book project is done, I can really dive into this stuff and have some fun.

On the non-technical front, my wife and I want to go on a well-deserved and long-delayed vacation. We’ll probably go to Sedona, AZ for sun and warmth – Seattle hasn’t had great weather the past few months and it’s starting to get to me. We’re also planning a long weekend trip to Whistler Mountain in Canada in a few weeks. I also look forward to spending some real quality time with my 3 year old son, Aidan. Aidan wrote the forward of my new book – you should check it out – he is very insightful for a 3 year old. There is a picture of he and I in the book too.

.NET Questions regarding JIT compiler/strong-naming security

JeffreyR — Mon, 25 Jul 2005 17:57:00 GMT

A reader of my books asked me some .NET Questions regarding JIT compiler/strong-naming security. I thought I'd share his questions and my answers with you:

1. According to Microsoft documentation the Just In-Time Compiler takes the following attributes of the machine into account when producing the executable code. Define how these factors alter the output. For example what is meant by CPU Type, what changes to the OS will affect the output.

· The version of the .NET Framework.

[JeffRichter] There may be bugs in the JIT that get fixed in a future release or the CLR may add some features that require that the code be produced differently. For example, in Whidbey, the JIT changes has a different way of calling interface methods than it had in Everett because some internal data structures changed.

· The CPU type (family).

[JeffRichter] The JIT compiler emits code depending on the type of CPU that is in the computer. Obviously code JITted for an x86 CPU will not run on an Itanium (IA64) CPU. But, the JITter can even produce different code for a Pentium 4 versus a Pentium 5.

· The version of the operating system.

[JeffRichter] The JITter may embed the address of some Win32 APIs in to the native code produced. The address of these APIs could change between different service packs of Windows XP (for example)

· The exact identity of the assembly (recompilation changes identity).

[JeffRichter] Obviously, if the assembly changes, the code must be re-compiled.

· The exact identity of all assemblies that the assembly references (recompilation changes identity).

[JeffRichter] The JIT can inline methods contained in one assembly when JIT-compiling a method in another assembly. If the referenced assembly changes, then this may have changed as well and the JITter needs to re-JIT using the new IL code.

· Security factors.

[JeffRichter] The JIT compiler checks security link demands and inheritance demands when JIT compiling to see if it is allowed to JIT compile.

2. What guarantees are there that the JIT compiler will produce the exact same executable every time it is run? How can this be verified?

[JeffRichter] There is no guarantee that this will happen and, in fact, it frequently doesn’t happen. Debug code and release code is completely different, for example.

3. With Strong named components what security testing has Microsoft done to ensure that another assembly can fake itself out to look like another assembly.

[JeffRichter] Strong-named assemblies are hashed and when the CLR loads them, it verifies the hash to ensure that no bits in the assembly have been changed. If a company’s private key is compromised (leaked), then there is no guarantee of security. Microsoft has tested the has algorithms and has modified strong-name assemblies to test they do not load.

I wish I had patented the idea of Zero, it was my idea first, really!

JeffreyR — Tue, 23 Nov 2004 02:11:00 GMT

Today, I discovered that Microsoft was filing a patent for “an operator that returns true when two memory addresses are not equal”!

See http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040230959%22.PGNR.&OS=DN/20040230959&RS=DN/20040230959.

Surely, we can still come up with better ideas than this to patent, can't we?

Plus, I think there is a lot of prior art around this particular invention.

Field access versus local variable access performance

JeffreyR — Sun, 14 Nov 2004 04:09:00 GMT

Recently, I was at a customer site and they were comparing the performance of a function that was written in unmanaged C with its C# equivalent. As they expected, the C code was performing much faster than the C# code. However, I didn't expect this. Once managed code is JIT compiled, the code is very similar to that of unmanaged code. The code was being called in a loop in both versios numerous times so the additional time spent by the JIT compiler should be noise and I expect the performance of the C# code to be near identical and even better than the unmanaged C version because the JIT compiler could emit optimizations for the speciifc CPU architecture of the host machine.

I was very interested in this problem and I closely examined both functions. Not just the source code, but I also very closely examined the machine code generated by the unmanaged C compiler as well as the machine code generated by the .NET Framework's JIT compiler. Not surprising (to me), the machine code was pratically identical. I did see a place where the C compiler emitted an INCrement instruction where th JIT compiler emitted an ADD instruction to add 1. I assume that this is because the JIT compiler knew the host CPU and determined that an ADD instruction would be faster than an INCrement instruction. This would actually make the managed code version faster.

I also noticed a place where the unmanaged version was updating a register directly where the managed version was updating a indirect memory location. This was because the unmanaged source code was updating a local variable while the C# version was turned into an object-oriented equivalent and as updating a field in the class object. This difference alse seemed minor to me and could not possibly accounting for the performance discrepency we were seeing. However, we continued to examine the code and in an effort to get the emitted machine code to be identical between the 2 as possible, we got rid of the field in the object and turned it into a local variable instead. WOW! What a difference this made in performance!

Apparently, the JIT compiler is able to enregister local variables but it cannot enregister fields. This makes sense since a field can actually be manipulated by multiple threads simultaneously or via other means behind a method's back and therefore, the JIT compiler takes the safe route of not enregisterring the local and always saves and fetches its value from memory. On the other hand, a local variable cannot be modified behind a method's back and therefor the JIT compiler can put it in a register.

I always knew that memory access is slower than CPU register access but I guess I nenver really knew how big a difference it could be. On the machine we were using to test this, the differenece was about 8 times. That is, the method with the field ran 8 times slower than the equivalent method with the local variable! On my notebook computer, the difference was much less: the local variable version ran in ~25 seconds while the field version ran in ~31 seconds. Still a pretty big difference.

So, the moral of the story, is that you should avoid field access as much as possible in performance-sensitive code. It might even make sense to copy a field into a loca, use the local in the method and then copy the result back from the local into the field just before the method exits. Below is some simple code (that requires Whidbey because I'm using the Stopwatch class) that you can compile and test on your own machine to see the perf difference:

using System;
using System.Diagnostics;

class App {
static void Main() {
const Int64 iter = 5000000000;

  Stopwatch sw = Stopwatch.StartNew();
  TestLocalAccess(iter);
  Console.WriteLine("time taken:{0} ticks", sw.Elapsed);

  sw = Stopwatch.StartNew();
  TestFieldAccess(iter);
  Console.WriteLine("time taken:{0} ticks", sw.Elapsed);
}

private static Int64 j;

public static void TestLocalAccess(Int64 numIncrement) {
Int64 j=0;
for(Int64 i=0; i<numIncrement; i++) j++;
}

public static void TestFieldAccess(Int64 numIncrement) {

for(Int64 i=0; i<numIncrement; i++) j++;
}
}