NGEN Improvements

Jim Hogg of Microsoft posted this little nugget on the DOTNET-CLR list in response to a question about how to get NGEN running as part of a setup script.

NGEN stores its results into the "Native Image Cache" -- physically, a collection of directories below \windows\assembly -- it's not actually the GAC, but brought to us by the same dev team.

Note that there's a couple of items to watch out for with using Custom Actions to trigger ngen: they need to run during a setup phase where it has SysAdmin privs; and as a consequence, there's a gotcha if the user disables rollback, yet ngen fails.  (I don't understand the details: my info is second-hand).

Also, beware of "servicing" issues.  For example, the user upgrades his machine; or changes security policy.  In these cases, your NGEN'd images may be rendered unusable.  In which case, the CLR will silently fall back to JIT'ing -- so it's not a fatal disaster -- all your Apps still work.  To guard against this, you might think about providing a small command file that the user can run to re-NGEN your assemblies, putting Humpty Dumpty back together again.

(As use/importance of NGEN grows, so we're working on making NGEN "self-healing" in the face of servicing -- for the Whidbey release)

I think the most interesting part about his (very nice) response is the last paragraph. Seeing hints like this about Whidbey is always interesting.

 

What’s especially interesting in this case is that it sounds like they’re about to make NGEN (potentially) a whole lot more useful. If you don’t already know, NGEN is the tool that pre-compiles your assemblies, to save the overhead of the JIT compilation that occurs at runtime. Today, NGEN isn’t very interesting, because any change to the system rightfully invalidates the compiled image and causes it to fall back on the regular JIT compiler. If NGEN images were self-recreating, it could provide a performance improvement, especially around startup times, which is where most of the JIT cost is. The tradeoff is a larger working set, but that might be worthwhile in some scenarios.

Pair Programming

Sam posts
a link to this
article which defends the use of pair programming, where two programmers collaborate
in front of a single computer to write software.  I’ve never tried this
formally in a professional setting, but I do have some experience with the phenomenon:
as an instructor I routinely write small programs in front of an audience. Anyone
that’s done this knows that the viewers don’t have to know the technology
you’re using very well to catch mistakes that you make.

In addition to this, I’m involved in a project right now where
the team is geographically distributed. I spend a lot of time on the phone, and even
with that relatively poor communication mechanism, we’ve had good luck working
through code together, both authoring and debugging. We got together in Minnesota
a few weeks ago, and had even better luck when we did the same thing with the code
up on a projection screen.

Of course, I think one of the contributors to the productivity increase
is that it makes you focus more. If I could write code for two hours straight on my
own without checking email or the web – something I wouldn’t do when I’m
using someone else’s time, too – I suspect I’d get more done. The
paper Sam references has some quantitative results, but I’d be curious to see
something more rigorous. And to try this approach myself some time, on some real project,
end-to-end.

I Like Pie

Tim Bray  posted this recently:

Sam Ruby has, over the last week or so, been quietly
at the center of a lot of intense discussion with the goals of clarifying
what a “log entry” is, and now building
a roadmap around it. Now they’re asking people to put up their hands and
say whether they support this or not. I support it strongly, with (a typically lengthy
list of) caveats, amplifications and digressions....

[ongoing]

The gist of it is, it might be time to pitch RSS, take the best ideas
out of it, and start over. Given the tarball that RSS is right now, I don’t
think this is a terrible idea. Had we done the same thing with HTML in about 1995
(and perhaps again around 1998), we might be in better shape today.

Certainly, the discussion on Sam’s
Wiki is interesting enough to be worth noting.

 

 

Managed Direct3D: Z-Buffers

It’s been a long hiatus, but now that I have my writing infrastructure working, I’m able to continue my managed Direct3D tutorial series.

The latest issue is about z-buffers, a technique for making sure that things that are behind other things look like they’re behind those things. You can find it here.  

I’ll hopefully be writing the next in the series this week, when I’ll deal with meshes. I’m on the hook to write more of these, as the series has been picked up by the German magazine DotNetPro. It was pretty funny to receive the issue in the mail, and not be able to read a word of the article.

CraigWriter.Write 2.1 in place

I’ve been working on completely overhauling my long-form writing infrastructure. It’s taken a lot longer than I wanted to, mostly due to my desire to do make use of CSS, and my inexperience with that technology. But I finally have something that I think will work for me and for you (for now).

You’ll notice a new link on the left: Writing 2.1. This will take you to where I’ll be putting all of my long form writing. I’ve already moved the managed Direct3D tutorial there. Although I’ll keep it where it is, all future updates and bugfixes will go in the new site.

At some point in the near future, I’ll post the code that I’m using to do this, but I’ve already spent way too much of my Sunday getting this stuff deployed. Still, I’m pretty happy with it – it already integrates with BlogX’s referrer tracking, and soon I hope to add features like RSS feeds for the long-form writing and deeper integration with the BlogX infrastructure.

If you see anything wrong with the HTML I’m producing (and I know you will – it’s got issues) please email me at candera@develop.com and I’ll try to fix it. I’d be especially appreciative if those of you who are more HTML-savvy than I could give it a once-over and tell me where I’m doing something stupid.

The XML Big Picture

If you were confused about XML, this
picture will help…or make it worse. :)

But the cool thing is, the pictures are linked to the specs.  

By way of Cedric Beust's
weblog.

Tim's Thoughts on AOP

I’ve been bothering Tim Ewald for a while to post a followup to my comments about AOP and code generation, since he was the one that inspired me to write about it in the first place. Well, he’s having trouble with his blog, so I’m posting it here. Now if only Ted Neward would get off his butt and post his response. :)

From Tim Ewald:

I've been hanging out with Craig a lot lately, he's doing some work for our team. He posted his thoughts on AOP a couple weeks ago and mentioned my work in that area. We've been carrying on the conversation ever since, and I promised him an online response.

 

I did a ton of work with AOP when I wrote Transactional COM+. By the end of that project, I had reached one main conclusion: call-interception is not a good, general purpose extensibility point. COM+ (at the time) was an entirely closed system with a fixed set of services that could be used in conjunction with one another. Even in that very finite universe, the interplay between the services is quite complex. Making that universe infinitely large by allowing third parties to mix in additional interceptors with arbitrary behaviors‚ is a mistake. The complexity goes through the roof, because, as Craig noted, the services typically are not orthogonal.

 

Is interceptor-based extensibility any worse than other types of extensibility? I think so. Method-level interceptors change the path from a call-site to a method's code. It's pretty hard to write reasonable calling code if you don't know how method invocation actually works and it varies on a case-by-case basis.

 

Probably the best example of the potential pitfalls is error handling. I want to get the exceptions thrown by the methods I call. If there are n interceptors between me and the method, that may or may not happen. Maybe an interceptor will catch the original exception, and throw a new exception. If I don't know that happened, how will I ever track down the real error? And what if the original function didn't cause an exception at all, it just left the world in a state that some interceptor didn't like? How do I know what happened? The path from a call-site to method code should be sacred. Interceptors can alter in ways that are not clear (and often are not documented), in essence encouraging "programming by side effect", which is a really bad idea.

 

COM+ 1.5 added support for "Services without Components", aka CoEnterServiceDomain, and Everett exposes this new functionality as managed code. No components means no interception, which I like. These APIs were really designed to allow COM+ services to be deeply integrated with low-level plumbing, but I like to use them in my own application code. Craig and I wrote an MSDN Magazine piece about how this works. However, judging by the ratings, most readers don't find the idea too attractive (or they just don't like our prose ;-).