I checked out and brought my luggage with me to the RAI. There is a luggage / cloak room where almost no one drops off their stuff, so I am using that one instead of the main one. Hopefully, it’ll save me some time when it is time to leave.
Yesterday I hung out with Steve for a while. It’s things like these that make tech-ed more than just about learning. As I mentioned earlier, it is nice to stay in touch with people across years.
DEV332: Async made simple in Windows 8, with C# and VB.NET
This session is hosted by Dustin Campbell
Async is the norm for Windows RT, where asynchronous programming is the only way to program. Synchronous programming and blocking is no longer acceptable for user applications, in order to ensure that applications are responsive and scalable.
Futures are objects representing pieces of ongoing work. They are objects in which callbacks can be registered that have to be executed when the work is ready to be completed (like doing something with downloaded data. Futures are basically syntactic sugar to make existing async programming patterns more palatable. The only downside is that you get nested lambdas for tasks that execute in several steps. Apparently, this is called macaroni code.
To fix this, C# has await and async keywords.
Await will take the rest of a method, and hooks it up as callback for the asynchronous event which is being handled. The Async keyword is used on the method itself to tell the compiler it has to do this. The callback will always appen on the sme thread that the operation was started from, so resource contention is not a problem, because while the code is running, the thread is not doing anything else.
So while your source code looks like something that is executing synchronously, it is actually broken in different pieces which are executed asynchronously. This is really neat, and it hides a lot of the ugliness of asynchronous programming. Even if you are not programming for Windows 8, this is a valuable feature for regular applications that require asynchronous programming.
Exception handling is built in, because the underlying IAsync operation captures it and presents it to the caller. Exceptions can then also bubble up through various completion tasks, and can be handled simply in the event handler like you would normally do. This is sweet, and much, much, much more convenient than if you had to deal with it manually
SIA311: Sysinternals primer: Gems
This session is hosted by Aaron Margosis. I’ve sen him present a similar talk a couple of years ago.
The room is not full. Plenty of seats are left open. I think this has to do with the fact that it is the last day. Aaron announced that there would be a book signing, but also mention that in their infinite wisdom, the organizers have decided not to have a bookstore on site. Yeah… I noticed. Someone should have his ass kicked because of it.
The entire session was demo driven, so I didn’t take notes. It was mainly about the unknown utilities or unknown features of well known utilities in the sysinternals suite.
DEV334: C++ Accelerated Massive Parallelism in Visual C++ 2012
This session is hosted by Kate Gregory, and covers the new C++ AMP tools which allow you to offload number crunching to the GPU. The room is not full, I suspect it has roughly the same group of people who were also at the pre-con sessions.
The session started with the overview of why you want C++: Control, performance, portability.
With AMP, your code is sent to an accelerator. Today, this accelerator is your GPU, but other accelerators might appear. The libraries are contained in vcredist, so you can distribute your AMP app just like any other app. And because the spec is open, everyone can implement it, extend it or add to it. Apparently, Intel have already done that.
They key to moving data to and from the GPU is a class array_view<T,N>, which represents a multi dimensional array of whetever. You populate those structures, and then perform the parallel_for_each() library function. This function will do all the heavy lifting and data copying for you. When the parall_for_each finishes, the result will be ready for you.
You an only call (other) AMP functions. All functions must be inlineable, use only amp supported types, and you won’t be doing pointer redirections or other C++ tricks. There is a list of things that are allowed and not allowed, but they are really all common sense.
There is also array<T,N>, which is nearly identical to array_view, but if you want to get data out, it has to be manually copied. At least that was my understanding. Things are going fast at this point so it is possible I’ve missed something.
If you want to take more control of your calculation, you can use tiling. Each GPU thread in a tile has a small programmable cache, which is identified by the new keyword tile_static. This is excellent for algorithms that use the same information over and over again. There is an overload for parallel_for_each which takes a tiled extent. However, the programmer is responsible for preventing race conditions -> use a proper use pattern with tile barriers
What is particularly interesting is that Visual Studio 2012 has support for debugging and visualization. You can choose debugger type CPU breakpoints and GPU breakpoints, and you need to debug on windows 8 apparently. It just works, and this was probably a huge chunk of work for someone, somewhere in the VS debugger team J
There is also a concurrency analyzer which is really good for figuring out CPU / GPU activity and how it correlates to your code.
That’s it for today. Time to go home.
I am glad attention got called to the fact that there is no bookshop. I’ll have to put that in the official feedback as well. And speaking of silliness: this tech ed there was exactly 1 session about the new C# keywords for asynchronous programming, and one on .NET 4.5 features. And for some inexplicable reason, they got scheduled in the same timeslot. Someone dropped the ball there as well.
Tech ed was a valuable experience yet again. I’ll post an overall tech-ed wrap-up tomorrow.