Month: July 2009

A New NProf Release?!

I guess what I posted about SlimTune must have made the rounds or something, cause three days after I said what I was doing, a new NProf was released. Here I went to all this trouble of creating a new profiler, and all I really had to do was complain 😀

I haven’t played with the new iteration in detail, but it does seem to have some nice new touches. I don’t actually believe it’ll be a competitor for me once I’m done — but hey, his is functional. Mine’s just a toy right now. I’m willing to concede at least that much. It’ll do the job for most people.

On a side note, after discussing with friends, I’m decided to use MIT license after all. I think it’s more advantageous to me to relieve any legal concerns that anybody may have than to maintain some vague semblance of control over the code. I’ve also more or less confirmed that SlimTune will be able to profile fully native apps eventually. It won’t be a feature in the initial release, most likely, but it’s coming.

Moar SlimTune

Primarily due to Washu request!

Mappings, native functions included!
Mappings, native functions included!

It's...an actual profile!
It's...an actual profile!

Another run, slightly improved SQL.
Another run, slightly improved SQL.

Tracking constructor calls!
Tracking constructor calls!

Remote Profiling will NOT be secure in SlimTune

At least, not to begin with. There are some drawbacks to not being a security professional, one of which is that I have neither the qualifications nor the experience to do a proper security analysis of the profiler backend. Since I can’t audit the backend for security, it will be considered insecure, and that’s that.

The practical result of this is that allowing uncontrolled remote connections to the profiler will be incredibly dangerous. I am planning to include a setting that disallows connections except from localhost. However, if you are actually using remote profiling on something that might be attacked, it’s critical to make sure it is behind a firewall that will not allow arbitrary connections.

Eventually it should probably allow you to set a username and password for connections, but that’s again something that takes some care to implement properly and I’d rather not be the one doing it. In any case, that’s functionality which will come much later. Sorry if secure remote profiling is high on your list.

SlimTune Profiler for .NET

I basically took last week off from blogging. Time to try and get some new entries out! Things have been very SlimDX focused, but what did you expect? It’s what I do. Maybe today’s will inspire a bit more general interest.

As a creature of GameDev.Net, I get to see lots and lots of discussions questioning whether or not C# and .NET are “fast enough” for games. What I don’t much is people working on actually analyzing and tuning the performance of their .NET code to see what’s going on. I’m not sure why this is, but I have a theory that it’s partly because of the sorry state of available performance tools. The only version of VS that has a profiler is Team Edition, which damned near nobody has. Other commercial offerings are also seriously expensive. There are only two free profiling tools that are really available for use: CLR Profiler and NProf. (I’ve seen a few other tools, but it’s clear that they’re fringe tools that aren’t well supported.)

CLR Profiler is written by Microsoft, and it’s a pretty good tool. They’ve even released the source code, although the licensing is vague. It has a few drawbacks though. First of all, it only does memory profile analysis. It does a very good job of tracking allocations and garbage collections, and the visualizations are very well done too. But that’s all you get — no timings of any kind, let alone a breakdown of where time is being spent. Also, it hasn’t been updated since late 2005.

Then there’s NProf. Oh dear. The good news is it works, barely. That bad news is that’s all the favorable comments I have about it. It does simple sampling based profiling only, and will show you a simple tree based breakdown of time spent. It’s not that NProf is useless; I’ve done lots of good performance tuning with it. But this is literally all it can do, and there’s a lot more you want from a profiler. The last release was December 2006, and there’s some scattered SVN traffic since then but it’s basically dead. Support for x64 is apparently doable if you compile from source. I looked at the source, which is also poorly written. I decided immediately that I could do better than this toy, and now I’m putting my money where my mouth is.

I’m working on a new open source profiler tool right now called the SlimTune Profiler. It will probably release in early September, and the initial feature set is taking direct aim at NProf. The initial version will support sampling and instrumentation profiling for .NET 2.0 and above on local and remote machines. A little later on, you’ll be able to profile-enable a long running process at zero performance cost, and then profile it in real time for short periods. Imagine running a production server, and actually connecting with the profiler while it’s serving real requests to see what’s happening.

On the front-end, data will be collected from the profiling backend and dropped into an embedded relational database. There will be some preset views of the data, but the idea here is that you should be able to apply your own queries to the data and get results that are useful to you. Reporting is not expected for the initial version, but it will be supported eventually as well. I imagine you’ll be able to create various tables, graphs, etc and export them, although I’m not sure exactly what format that’ll be in. PNG and Excel seem reasonable. I’m hoping that you’ll be able to combine results from multiple runs, which would allow you to make all kinds of snappy graphs to show off to your boss.

It’s been my plan for some time now to expand beyond SlimDX, and create a suite of Slim software. We’ve got a good reputation and lots of respect for our work, and I’m looking to build on that. SlimTune is the first step. It probably won’t be able to compete with the commercial offerings — but RedGate ANTS runs $400 or more per license. SlimTune will blow NProf out of the water in a scant two months, and it won’t cost you a dime. The feature set is pretty well specified, and the profiler already works in prototype form. The work over the coming weeks is in building a product instead of a project.

And yes, I know I’m a tease. It’ll be worth the wait.

Export and Import Interoperability

I’ve decided that “Windows API Code Pack” is far too long to say/write in casual conversation. WACP it is.

These are terms I came up with a few weeks ago, and I wanted to document them properly. I feel that they’re good descriptions of what a wrapping API like SlimDX allows, and it’s useful to be able to settle on common jargon. The basic idea of interoperability is for libraries to be able to cooperate, by sharing objects with each other.

Export interoperability is the ability to “export” objects to other libraries. In the case of SlimDX and similar wrappers, it essentially involves exposing the internal IUnknown pointers, so that another system that supports importing objects can do so. It’s not difficult to implement, but it is critical to remember that when your objects are exported, their state can be changed at any time, outside of your control. You can’t cache anything that isn’t invariant. This is why XNA is unable to do export interop; they chose to cache just about everything, and allowing people to use the underlying interfaces directly will break it. People do it anyway via reflection of course, but it’s risky. SlimDX and WACP don’t cache anything about the objects, and support export interop cleanly. This is why we can work with libraries like DirectShow.NET, CUDA.NET, and more.

Import interop is of course the ability to consume objects from another library. Of the various DirectX wrappers, SlimDX seems to be the only one that handles import interop. There’s no particular reason WACP can’t do it, as far as I can tell; they simply haven’t added it to the public interface. With XNA, I believe that the cached values are again the problem, I suspect. They could be looked up on construction, but somebody else still has direct access to the interface. Import interop is at its core not that clever, because it’s a basic part of building the wrapper in the first place. You have to be able to convert pointers from the unmanaged API to your own objects, so it’s not a big step to do it from arbitrary pointers. The trick is doing it safely; you have to trust that the pointer you’re given is what the caller says it is. SlimDX assumes it is an IUnknown and then uses QueryInterface to get the desired type. This is our only line of defense, but it’s a fairly effective one.

Interoperability has been a major focus for the SlimDX design, for both import and export. There’s a fair amount of complexity involved in object construction, but it’s been carefully laid out to be able to handle external pointers. There was some internal caching of values early on, which we thought were invariant, but we were seeing some difficult to track problems and so we backed out the code to a safe implementation. Our commitment to making sure we can both export and import objects goes far beyond the other major wrappers, although WACP should be able to provide equivalent functionality if they stick to the current design or similar.

Quick Update

So I’m heading home for the weekend, and I’ve exhausted my queue of posts for the moment. I’ll be bringing you guys the next part of the SlimDX Architecture series some time next week, and we’ll see where things go from there. I’m also going to evaluate whether or not to do an interim SlimDX release for July; I’ve just gotten word that the SDK is not going to be released for some time.

I am now a DirectX MVP!

I’ve just been awarded XNA/DirectX MVP status by Microsoft! I’m still poking around the new sites I’ve been given access to, but there’s a lot of cool stuff here, courtesy of Microsoft. They’re giving me MSDN and TechNet subscriptions, for example, which I’m thrilled about. I’m also eager to finally have access to the private MVP newsgroup, since it’s not uncommon that I have questions related to SlimDX development that really need an answer from the DirectX team itself.

In short, this is pretty awesome.