- Event Kickoff
- Keynote - Scott Guthrie
- Silverlight Overview - Tim Heuer
- Expressions 3 Overview - Adam Kinney
- Sketch Flow - Janete Perez
- Silverlight Toolkit - Marcos Matos
- .Net RIA Services - Brad Abrams
- Silverlight UIs with XAML Powertoys - Karl Shifflett
Wednesday, September 30, 2009
Silverlight Firestarter Videos Available
About two weeks ago David Makogon made a post about what then was an upcoming day-long presentation about Silverlight 3. If you missed it the videos are now available on-demand through Silverlight streaming playlist. The playlist sections include the following.
Friday, September 25, 2009
XNA on the Zune HD
The Zune HD was released a little over a week ago and I received the unit that I had ordered. One of the first things I did (after loading my music) was to take a look at what had changed in the XNA framework for the ZuneHD. In case you are unfamiliar with it the XNA framework is a .Net based library created by Microsoft for making games. XNA Framework based applications can be run on a PC, on the Xbox 360, or on the Zune. It can either be used with Visual Studio 2008 or Visual Studio Express. With the release of the Zune HD Microsoft added two new classes: the Accelerometer and the TouchPanel. It seems that on every accelerometer equiped device that I've seen there's a digital level available for it. So in sticking with tradition I decided that I'd create one for my Zune HD.
Using Expressions Design I was able to make a few simple graphic assets, imported them into Visual Studio, and had the program up and running in a short period of time. After making the program and seeing that it worked I uploaded a video of it and later received a few request for the source code.
So I've uploaded the source code to the program to CodeProject.com along with a description of how the code works and how it was put together. If you are interested check it out.
Wednesday, September 23, 2009
Math Without a Floating Point Unit
The everyday development that I do targets desktop processors. The processors are more than capable of meeting the computational demands and performances requirements so its rare that I ever have to think about how long it takes to execute a specific mathimatical operation. But while that's the general case it isn't always the case.
When I was finishing grad school one of my projects dealt with machine vision and automatic classification of photographs. I had an understanding of the algorithms I needed to implement and how everything was going to fit together. During development of the individual components I used small datasets that were sufficient for letting me know that the components were working as designed. It wasn't until I had brought all of the components together that I gave the system full sized images to process (around 2 megapixel) . I knew that a full sized image would take longer to process, but processing of the image took around three hours! In reasearching the cause of the slowness I found that some of the functions I was trying to execute were not nativly supported by the machine's processor and were being emulated. Some of the math operations consumed 50 to 100 times more time than the native operations. There was a time constraint on the exeution time of this program since I had to demonstrate its execution in class during a presentation. To stay within those constraings the more expensive mathimatical operations were replaced with lookup tables and the program was changed from just being multithreaded to taking full advantage of multiprocessing.
In the past few weeks I was reminded of the experience after getting a couple of e-mails from other developers that were trying to figure out why their programs were having such poor performance. Both developers were creating programs that performed graphical processing and both were targetting Windows Mobile devices (which use ARMS processors). ARMS processors are available with a broad range of performance characteristics. On the lower end the processors only support integer operations, have no divide instruction, and typically run around 200 MHz. On the upper end the processors may have hardware implementation for floating point operations (including a divide instruction), built in 3D graphic accelerators, and run at up to 1 GHz. Both of the developers were testing their programs on devices that had no native floating point support and no divide instruction. So these operations were being emulated. That information alone was enough to answer their questions. But I decided to do a few measurements.
I dug up every ARMs based device running a Microsoft OS that I could find. In my possession I have several Windows Mobile devices from PocketPC 2002 devices to a newly released device that will soon have Widnows Mobile 6.5. The Microsoft Zune is also ARMS based. So I included it in my test. I've also got remote access to a few newly released devices. For the test I had each device perform a million additions, subtractions, multiplications, and divisions for both integer numbers and double-precision floating point numbers. For the Windows Mobile devices I did this using native (C-language) programs since the .Net Compact framework does not support floating point operations. For the Zunes I used .Net through the XNA framework. The Zune version of the .Net framework supports floating point operations. Because of the broad range of clock frequencies that these devices used for each device I used the time taken to perform a million additions as a base measurement. My findings were fairly consistent. In general the devices that had no floating point support took about 30-times longer to perform a division on a double-precision number than the integer addition. Devices that had floating point support took about 2-time longer to perform a double-precision division than addition.
The algorithms that both developers were implementing made heavy use of floating point operations. There had been some expectations made about the performance of the programs when run on a mobile device that had been transfered from experience with desktops. Desktop processors have a more complete set of hardware implemented math operations than mobile processors. Both developers also had the same device which had no floating point support. So it comes as no surprise why the algorithms were running so slow. So what could they do about it? There's no universally satisfying substitute for a capable hardware so the exact solution is going to depend on what one is trying to accomplish. For one developer an acceptable solution was to use a different algorithm that produced acceptable results and had a much lower computational demand. For the other developer compromises on the result were not as acceptable so the hardware requirements for his software were revised so that they identified the needed hardware.
The experience from school and the experience of the two developers underscore the importance of making sure that solution's hardware and implementation are in sync with each other.
When I was finishing grad school one of my projects dealt with machine vision and automatic classification of photographs. I had an understanding of the algorithms I needed to implement and how everything was going to fit together. During development of the individual components I used small datasets that were sufficient for letting me know that the components were working as designed. It wasn't until I had brought all of the components together that I gave the system full sized images to process (around 2 megapixel) . I knew that a full sized image would take longer to process, but processing of the image took around three hours! In reasearching the cause of the slowness I found that some of the functions I was trying to execute were not nativly supported by the machine's processor and were being emulated. Some of the math operations consumed 50 to 100 times more time than the native operations. There was a time constraint on the exeution time of this program since I had to demonstrate its execution in class during a presentation. To stay within those constraings the more expensive mathimatical operations were replaced with lookup tables and the program was changed from just being multithreaded to taking full advantage of multiprocessing.
In the past few weeks I was reminded of the experience after getting a couple of e-mails from other developers that were trying to figure out why their programs were having such poor performance. Both developers were creating programs that performed graphical processing and both were targetting Windows Mobile devices (which use ARMS processors). ARMS processors are available with a broad range of performance characteristics. On the lower end the processors only support integer operations, have no divide instruction, and typically run around 200 MHz. On the upper end the processors may have hardware implementation for floating point operations (including a divide instruction), built in 3D graphic accelerators, and run at up to 1 GHz. Both of the developers were testing their programs on devices that had no native floating point support and no divide instruction. So these operations were being emulated. That information alone was enough to answer their questions. But I decided to do a few measurements.
I dug up every ARMs based device running a Microsoft OS that I could find. In my possession I have several Windows Mobile devices from PocketPC 2002 devices to a newly released device that will soon have Widnows Mobile 6.5. The Microsoft Zune is also ARMS based. So I included it in my test. I've also got remote access to a few newly released devices. For the test I had each device perform a million additions, subtractions, multiplications, and divisions for both integer numbers and double-precision floating point numbers. For the Windows Mobile devices I did this using native (C-language) programs since the .Net Compact framework does not support floating point operations. For the Zunes I used .Net through the XNA framework. The Zune version of the .Net framework supports floating point operations. Because of the broad range of clock frequencies that these devices used for each device I used the time taken to perform a million additions as a base measurement. My findings were fairly consistent. In general the devices that had no floating point support took about 30-times longer to perform a division on a double-precision number than the integer addition. Devices that had floating point support took about 2-time longer to perform a double-precision division than addition.
The algorithms that both developers were implementing made heavy use of floating point operations. There had been some expectations made about the performance of the programs when run on a mobile device that had been transfered from experience with desktops. Desktop processors have a more complete set of hardware implemented math operations than mobile processors. Both developers also had the same device which had no floating point support. So it comes as no surprise why the algorithms were running so slow. So what could they do about it? There's no universally satisfying substitute for a capable hardware so the exact solution is going to depend on what one is trying to accomplish. For one developer an acceptable solution was to use a different algorithm that produced acceptable results and had a much lower computational demand. For the other developer compromises on the result were not as acceptable so the hardware requirements for his software were revised so that they identified the needed hardware.
The experience from school and the experience of the two developers underscore the importance of making sure that solution's hardware and implementation are in sync with each other.
Thursday, September 17, 2009
Silverlight Firestarter online
Microsoft's Silverlight Firestarter is online now, streamed via Silverlight. Go here to connect.
The slides are available here.
Presenter pages:
The slides are available here.
Presenter pages:
- Scott Guthrie: http://weblogs.asp.net/scottgu/
- Tim Heuer: http://timheuer.com
- Adam Kinney: http://adamkinney.com/
Thursday, September 10, 2009
Upcoming talk: Intro to SketchFlow
On October 14, I'll be presenting an intro to SketchFlow, the UI prototyping tool built into Microsoft Expression Blend 3.0. The talk will be at the monthly Rockville .NET User Group meeting in Rockville, MD. See http://www.rocknug.org/ for more info and directions.
Stick around afterward for Q&A, plenty of pizza, and an ASP.NET 4.0 talk by Kevin Jones, a local Microsoft MVP.
Stick around afterward for Q&A, plenty of pizza, and an ASP.NET 4.0 talk by Kevin Jones, a local Microsoft MVP.
Subscribe to:
Posts (Atom)
