Technical Challenge of Multiple CPUs

One of the biggest technical challenges in developing software is taking advantage of multiple CPUs. Processor speed has basically stalled. Intel and AMD are putting more and more CPUs into the same chip. Right now dual and quad core chips are becoming common. If you are talking two years away, then by Moore's Law, you will be seeing eight or more cores in most systems. If it is three years away, you could be seeing sixteen or more cores.

Currently, only very high end systems have multiple GPUs. We had one system at a company I used to work for that had four GPUs (all very high end stuff doing medical imaging). But just like CPUs, multiple GPUs are going to be more and more common.

The challenge of writing code that supports multiple processors working in parallel is the real challenge. Some argue that current computer languages do not support that well. In my experience, threads (which are supposed to be light weight processes) do not scale well on multi-core CPU systems. We had a Java application with six main threads running on a system with two dual core chips (total of 4 cores) and we saw almost no performance gain for that application over running on a single core CPU. The system performed better because the system basically gave one CPU to the SQL server and another to the OS, but our multi-threaded application did not get any faster. You could blame that on Java, but putting the blame there does not solve the problem. Also we had similar problems with a multi-threaded application written in C++. The current state of compiler and operating system support for multiple CPUs is limited.

Right now I am drooling over the new Alienware M17x. You can get a laptop with a quad core CPU and dual GPUs. That would be a good replacement for aging Alienware laptop. It has been a great system, but it is getting old.

I hope that the operating system and programs will take full advantage of the 16 CPUs and 8 GPUs I hope to have in the computer I hope to have in a couple of years.

First Impression of Windows Mobile 6.5 Developer Tool Kit

I downloaded and installed the Windows Mobile 6.5 Developer Tool Kit. My first impression is yawn. I am putting a lot of emphasis on Windows Mobile but I found the 6.5 developer tool kit to be a big disappointment. The tool kit includes two new features: gesture API and widgets.

Personally, I think the gesture API is a yawn. I don't mind using a stylus. I have a nice set of pens that can print in black, red, pencil, or act as a stylus. People don't complain about using a pen on a piece of paper; why do they complain about using a stylus on a device? With a multi-function tool that can act as a pencil, pen, or stylus, I don't have to put the tool down to use a phone or PDA. I will have to play with the gesture API, but at this point it is just a yawn.

My first thought about widgets was so what? My second thought was about the same. The only reason widgets are at all interesting is they point out the capabilities of the new browser included on Windows Mobile 6.5. It is too early for me to tell, but that may be a reason alone to upgrade to 6.5. The only thing that worries me is the example widget posted by Microsoft does not use cascading style sheets or JavaScript. The "hello world" example makes me worry that the support for CSS and JavaScript may still be a little lacking. I will wait until someone else spends the time and effort documenting what works and what does not before do anything serious with widgets. One interesting thing about widgets is Microsoft actually points to the W3C standard for Widgets. A Google search about Widgets pulls out this gem: Apple threatens to block W3C widget standard. I am not worried that Apple's attempt to block the W3C will have any impact on Microsoft. After all, Microsoft will do what it has always done, create a non-standard way. But this time Microsoft could say, "Don't blame us, Apple forced us to."

The 6.5 tool kit screams, "I was pushed out quickly!" A lot of documentation about 6.5 on the MSDN site is missing. I found several broken links just trying to find out what was new. Another thing that reinforces that is the DRK or Developer Resource Kit will not be available until July. Microsoft is going to charge $9.99 for the DRK. I was going to order a copy. However the MSDN order site asked for my credit card without using a secure web page. The page does not display the little lock icon in IE8. This is probably another bug caused by pushing out the release. Until Microsoft fixes this, I will not put my credit card information into an unsecure web page. I discourage anyone from ordering the DRK until you can order it from a secure web page.

Unless you are hot for the gesture API or want to explore the capabilities of the new browser there is little need to download the Windows Mobile 6.5 Developer Tool Kit.

Converting Campaign Cartographer Files to XAML Revisited

I have spent a lot of time working with Campaign Cartographer 3, Adobe Illustrator CS, Corel Draw 12, and Expression Blend 3. I finally came up with a solution on how to create a XAML file from Campaign Cartographer 3. CC3 will export a Windows Metafile (.emf). Adobe Illustrator CS sometimes has problems with these files. The solution is to open the .emf file in Corel Draw and save the result as an Adobe Illustrator file. This also offers the opportunity to convert all the text to curves. Adobe is very proprietary about fonts. Converting text to curves fools Adobe Illustrator and you have no more issues with fonts, at the cost of a bigger file.

After saving the file as an Adobe Illustrator file from Corel Draw you need to load the file into Adobe Illustrator and save it out again. Expression Blend 3 will not load the files created by Corel Draw. Adobe Illustrator adds "[converted]" to the file name when it saves the file.

Now you can load the converted Adobe Illustrator file directly into Expression Blend. You may need to do a few transformations to move and scale the map but it works.

If you export something small from CC3, then you must scale it up in Corel Draw. Full maps work without the need to scale it up.

Why Windows Mobile?

One of the questions I always get when I present the business concept for JSM Software is "why did you choose Windows Mobile?" Some are even less subtle and ask, "Why not develop for the iPhone instead?" They usually follow up with the story about how a friend of a friend made a lot of money selling some application on the iPhone.

Anecdotal evidence is not a good reason to start a company. I know a friend of a friend that won the lottery. It makes as much sense spending all my time, effort, and money trying to win the lottery as it does trying to make a lot of money creating applications for the iPhone. Both have the same anecdotal evidence.

I am trying to build a company, not win the lottery. I worked for a company that tried to "win the lottery". They came up with wonderful ideas that would change the entire company. None of it ever came to fruition. I want to emulate the conservative playbook of Woody Hayes, "three yards and a cloud of dust". Another description was "crunching, frontal assault of muscle against muscle, bone upon bone, will against will." Paraphrasing Woody Hayes, "a company will not succeed unless they regarded the challenge positively and would agree to pay the price that success demands of a team."

My business philosophy is simple: I want to grow a dedicated customer base by continually creating quality products. Sure I would like to make a lot of money. Everyone does. I will only focus on a market I know will provide adequate compensation for my effort.

One reviewer wrote me, "The iPhone market is so oversaturated with bad games, it's unbelievable." The vast number of cheep bad games put tremendous downward pricing pressure. Rick Storm wrote in his blog The Incredible App Store Hype, "The hype surrounding the iPhone App Store continues to persist." Rick Storm has an application is listed as #34 on the social networking chart. According to his blog that makes him a little over $20 per day. That is a little over $7000 per year if sales continue at that rate. That is not a lot of money to me.

Owen Goss documented his success with his game Dapple on his blog. Owen Gloss wrote about developing applications for the iPhone, "...I suspect we'll see fewer and fewer stories about people getting suddenly very rich." (The Numbers Post (aka Brutal Honesty)). Owen Gloss spent $32,000 developing Dapple and made a total of $535 in revenue. Playing the lottery sounds like it has a lot better odds than that. I fully agree with Owen Gloss, "My hope is that we'll start seeing more developers putting out quality titles in the hopes of gradually growing a sustainable business." Owen Gloss strongly implies developing games for the iPhone is not currently a sustainable business.

This reminds me of a stanza from one of my favorite poems, "The Gods of the Copybook Headings" by Rudyard Kipling:

With the Hopes that our World is built on they were utterly out of touch.
They denied that the Moon was Stilton; they denied she was even Dutch.
They denied that Wishes were Horses; they denied that a Pig had Wings.
So we worshiped the Gods of the Market Who promised these beautiful things.

I hear a lot of people worshiping the Gods of the Market in the form of praising the iPhone App Store.

Before deciding on Windows Mobile I did a lot of research. This is something it appears many jumping into the fray of developing software for mobile devices do not do. Denise Marcus, a friend of mine, always said, "Do the numbers." I have always been amazed at how many people fail to do the numbers.

What are the numbers? According to wmpoweruser.com (Windows Mobile hits 50 million lifetime sales ) Microsoft has sold over 50 million Windows Mobile devices. Of that, approximately 30 million are currently in use. These numbers make sense. According to Gartner, Microsoft has been selling over 4 million windows mobile devices every quarter since 2007 (Gartner Says Worldwide Smartphone Sales Reached Its Lowest Growth Rate). Most mobile contracts are two years long. 4 million per quarter times 4 quarters per year times 2 years equals 32 million. The 30 million number may be a bit low, but it is a reasonable starting point.

According to Entertainment Software Association 36% report they play games on a wireless device such as a cell phone or PDA (Essential Facts About the Computer and Video Game Industry). That means that 10.8 million Windows Mobile Users play games. The Entertainment Software Association also said that 7.6% of people who play games play role playing games. Conservatively the market for the type of games created by JSM Software is eight hundred and twenty-one thousand (821,000). If JSM Software reaches a one half of one percent market penetration, 0.5%, the sales projection is four thousand one hundred units (4,100).

My budget for creating a game is about $20,000. That means I need to make about $5 per unit sold. That does not include all the overhead costs in addition to the $20,000 budget. The interesting point is the average price of a role playing game for Windows Mobile on Handango is about $20. After crunching the numbers and using the wonderful spreadsheet provided by SCORE I determined I could make a living if I sold the game for $15 and sold a total of about 4,100 units over the lifespan of the game which I estimated to be one year. I bounced these numbers off of the CEOs of two other game companies. One CEO said my figures were "spot on".

Owen Goss said he needed to sell 9,150 units of Dapple before he would break even. I leave it to the reader to figure out what percentage of the market Dapple would require to break even. I am pretty sure it would be much larger than 0.5%.

The thing that puzzles me the most is why some people are so adamant I should develop for the iPhone? It seems they are trying to evangelize me to the iPhone religion. They believe all the hype and anecdotal stories. My choice to develop for Windows Mobile is an informed decision based on research. I am not embarking on creating a company based on anecdotal stories.

Problems with Practical Web 2.0 Applications with PHP

I wanted to use the code from Quentin Zervaas's book for a website. There is a lot of good material in the book. Unfortunately, the development environment used by Quentin Zervaas must be very different from my development environment.

I could not get the code to work for days. I kept fumbling around and fumbling around trying to figure out what was wrong. The first problem was the index page code was crashing and leaving no log. It took me a while, but the problem was with the EmailLogger code bye Zervaas.

I am running on a Fedora 10 Linux development server. This is a minimally configured virtual machine running on my under powered VM server. This is not a production server. The first problem comes from the minimal configuration. Zervaas wrote the following code in the file "index.php":

$writer = new EmailLogger($_SERVER['SERVER_ADMIN']);

The code is simple enough it passes the "SERVER_ADMIN" name to the EmailLogger function. On a minimally configured system the value of "SERVER_ADMIN" is "root@localhost".

The EmailLogger function calls Zend_Validate_EmailAddress to make sure the email address is valid. The code is shown below:

$validator = new Zend_Validate_EmailAddress();

The default constructor for the Zend_Validate_EmailAddress only allows DNS hostnames. This means that "root@localhost" is not a valid email address using the default parameters when creating Zend_Validate_EmailAddress. This took a long time to figure out.

The solution is to tell the constructor to allow both DNS and local names. The code to do that is below:

$validator = new Zend_Validate_EmailAddress(Zend_Validate_Hostname::ALLOW_DNS | Zend_Validate_Hostname::ALLOW_LOCAL);

The support site for "Practical Web 2.0 Applications with PHP" does not document the problem with the email validation. The support site did document the next problem I ran into. This was extra slashes at the beginning of each URL. Instead of the URL being "/index" it was "//index". I tracked down the problem quickly. But every solution that made sense to me failed. The support site has two lists of errata for the book. One list is the old and unmaintained list. The other list is the new and maintained list. The new list does not contain the errata listed on the old list.

A more subtle problem is the wording of the errata. The old and unmaintained list of errata states, "When using Zend Framework 1.0.3 URLs will be generated beginning with 2 slashes." What the errata should have said is "When using Zend Framework 1.0.3 or newer URLs will be generated beginning with 2 slashes." I installed the Zend Framework 1.7.8.

I now have a problem with Captcha and image generation. This has been yet another learning experience.

Rounding Error Are an Important Consideration

My background includes a lot of mathematical analysis. I took a lot of numerical analysis at the University of Utah. Many more classes than were actually required because I enjoyed the combination of math and programming. In addition, I was a teaching assistant for the computational physics classes taught as part of the master's of instrumentation program of the physics department. My first job when I left the University of Utah was working on mathematical educational software. My assignment was part of a group creating a system that symbolically solved mathematical problems. I learned a lot. One of the challenges was checking the work of the system. I spent months doing nothing but math. After giving the system a problem it would generate an answer. Often the answer didn't match the solution printed in the book. We had to determine if the computer's answer was actually the correct answer. The system may not have simplified the answer, or not done some trigonometric substitution or maybe the answer in the book was wrong. It was a lot of work. That taught me the importance of mathematical simplification.

Years ago I worked on a respiratory therapy patient demographic and therapy management system. The company's core intellectual property was the set of equations modeling the treatment efficacy. The equations took the raw numbers provided by the medical instruments and the patient demography and created a meaningful human understandable diagnosis. My task was implementing those equations on a new system. I took one look at the equations and knew something was wrong with them. My background in numerical analysis told me curve fitting software created the equations. The curve fitting software mathematically matched the curve but did not simplify the equations. I convinced the professor that created the equations I could simplify them. For the next month I proved symbolically and numerically my simplification of the equations was correct. Imagine working on a month long math test. I proved the error analysis of my equations was significantly smaller than the original equations. More importantly, the resulting program ran more than ten times as fast.

What does all that have to do with XAML, hex grids, and user controls? You would think I would know better. I start working on making a hexagon a user control and what bites me? Rounding errors! I should have known that rounding errors would cause problems.

I started working on converting the shaded hexagon from my previous blog into a user control. I needed to work out the coordinates where to put each hexagon to create a hex grid. I created a column of hexagons. They looked good. I then added a second column, a third, and a fourth. Things looked great as you can see below.

Then I zoomed in a bit. Then I noticed that the hexagons did not always touch. I immediately knew the problem: rounding errors. You can see that below.

Hexagons tile the plane. Unfortunately you cannot tile them in XAML because you can only tile using simple rectangular patterns. I could use more precision. That would make the problem less likely to appear. The other option is just to make the hexagon grid as a series of polygons; each one calculated using as much accuracy as possible. You can see that below.

It looks like all is well with the hex grid. Until I made a simple change: I changed the stroke width to zero. You can see the result below.

Rounding errors are still visible. What does that mean? The short answer is you cannot expect to perfectly replicate a hexagon grid.

No Geometry Resources in Silverlight 2

I wanted to create a hexagon grid. There is a good article on how to draw a hexagon grid using C# code here.

I wanted to create my grid in XAML. I used Excel to do the calculations. I also used Excel to generate the polygon points statement. The simplest hexagon in XAML I could come up is coded like this:

<Canvas
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="480"
    Height="480"
>
    <Polygon Stroke="#000000" StrokeThickness="1" Points="0,35,20,0,60,0,80,35,60,69,20,69"/>
</Canvas>

That looks like this:

My next step was to set up a nice radial fill. I put the fill as a static resource. The resulting code looks like this:

<Canvas
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="480"
    Height="480"
>

    <Canvas.Resources>
        <RadialGradientBrush 
            x:Key="HexRadialFill"
            GradientOrigin="0.5,0.5" 
            Center="0.5,0.5" RadiusX="0.5" RadiusY="0.5">
            <RadialGradientBrush.GradientStops>
                <GradientStop Color="LimeGreen" Offset="0" />
                <GradientStop Color="Green" Offset="1" />
            </RadialGradientBrush.GradientStops>
        </RadialGradientBrush>
    </Canvas.Resources>

    <Polygon Stroke="#000000" StrokeThickness="1" Fill="{StaticResource HexRadialFill}"
        Points="0,35,20,0,60,0,80,35,60,69,20,69"/>
</Canvas>

The resulting image looks like:

I now planned on making the polygon a resource. Unfortunately you can't do that in Silverlight 2. I looked into converting the polygon into a path and then putting that as a geometry resource. Alas, Silverlight 2 does not allow geometry resources.

I have a couple of options. I could make the hex a user or custom control. That would allow code reuse. But at this time, I just want a hex grid. The quick and dirty way is to just write some more macros in Excel and generate the entire grid as a bunch of polygon statements. I could do that probably quicker than it took me to write this blog. However, I am dedicated to quality. I would never allow a developer who worked for me to hack out something quick and dirty like that. That means I need to create a user control and code that up. It will take me longer to code up the user control. The advantage is the resulting code will be reusable (even though I doubt I will reuse it).

I now know what it was like to work for me. I am somewhat of a demanding manager. I want things done the right way with no quick and dirty solutions. Now I can say I apply that standard even to my own work.