Smartphones and Tablets Go Multicore: Now What?

Within three years, nearly 75 percent of smartphones and tablets will have a multicore processor, predicts In-Stat, a research firm. This trend is no surprise, considering how mobile devices are increasingly handling multiple tasks simultaneously, such as serving as a videoconferencing endpoint while downloading email in the background and running an antimalware scan.

Today’s commercially available dual-core mobile devices include Apple’s iPad 2, HTC’s EVO 3D and Samsung’s Galaxy Tab, and some vendors have announced quad-core processors that will begin shipping next year. Operating systems are the other half of the multicore equation. Android and iOS, which are No. 1 and No. 2  in terms of U.S. market share, already support multicore processors.

“IOS and Android are, at their core, based on multithreaded operating systems,” says Geoff Kratz, chief scientist at FarWest Software, a consultancy that specializes in system design. “Android is basically Linux, and iOS is based on Mac OS, which in turn is based on BSD UNIX. That means that, out of the box, these systems are built to support multicore/multi-CPU systems and multithreaded apps.”

For enterprise developers, what all this means is that it’s time to get up-to-speed on programming for mobile multicore devices. That process starts with understanding multicore’s benefits -- and why they don’t always apply.

Divide and Conquer

Performance is arguably multicore’s biggest and most obvious benefit. But that benefit doesn’t apply across the board; not all apps use multithreading. So when developing an app, an important first step is to determine what can be done in parallel.

“This type of programming can be tricky at first, but once you get used to it and thinking about it, it becomes straightforward,” says Kratz. “For multithreaded programming, the important concepts to understand are queues (for inter-thread communications) and the various types of locks you can use to protect memory (like mutexes, spin locks and read-write locks).”

It’s also important to protect shared data.

“Most programmers new to multithreaded programming assume things like a simple assignment to a variable (e.g., setting a “long” variable to “1”) is atomic, but unfortunately it often isn’t,” says Kratz. “That means that one thread could be setting a variable to some value, and another thread catches it halfway through the write, getting back a nonsense value.”

It’s here that hardware fragmentation can compound the problem. For example, not all platforms handle atomic assignments. So an app might run flawlessly on an enterprise’s installed base of mobile devices, only to have problems arise when non-atomic hardware is added to the mix.

“Using mutexes (which allow exclusive access to a variable) or read/write locks (which allow multiple threads to read the data, but lock everyone out when a thread wants to write) are the two most common approaches, and mutexes are by far the most common,” says Kratz. “For Android programmers, this is easily done using the ‘synchronized’ construct in the Java language, protecting some of the code paths so only one thread at a time can use it.”

For iOS, options include using POSIX mutexes, the NSLock class or the @synchronized directive.

“Ideally, a programmer should minimize the amount of data shared between threads to the absolute bare minimum,” says Kratz. “It helps with performance and, more importantly, makes the app simpler and easier to understand -- and less liable to errors as a result.”

No Free Power-lunch

As the installed base of mobile multicore devices grows, it doesn’t mean developers can now ignore power consumption. Just the opposite: If multicore enables things that convince more enterprises to increase their usage of smartphones and tablets, then they’re also going to expect these devices to be able to run for an entire workday between charges. So use the extra horsepower efficiently, such as by managing queues.

“You want to use a queue construct that allows anything reading from the queue to wait efficiently for the next item on the queue,” says Kratz. “If there is nothing on the queue, then the threads should basically go idle and use no CPU. If the chosen queue forces you to poll and repeatedly go back and read the queue to see if there is data on it, then that results in CPU effort for no gain, and all you’ve done is use up power and generate heat. If a programmer has no choice but to poll, then I would recommend adding a small sleep between polling attempts where possible, to keep the CPU load down a bit.”

When it comes to power management, many best practices from the single-core world still apply to multicore. For example, a device’s radios -- not just cellular, but GPS and Wi-Fi too -- are among the biggest power-draws. So even though multicore means an app can sit in the background and use a radio -- such as a navigation app constantly updating nearby restaurants and ATMs -- consider whether that’s the most efficient use of battery resources.

“For some apps, like a turn-by-turn navigation app, it makes sense that it wants the highest-resolution location as frequently as possible,” says Kratz. “But for some apps, a more coarse location and far less frequent updates may be sufficient and will help preserve battery.

“There may be times where an app will adapt its use of the GPS, depending on if the device is plugged into power or not. In this case, if you are plugged into an external power source, then the app can dial up the resolution and update frequency. When the device is unplugged, the app could then dial it back, conserving power and still working in a useful fashion.”

Photo Credit: @iStockphoto.com/skodonnell

4 Key Principles for Creating Truly Open Open-source Projects

Scratch the surface of virtually any business, and you’ll find open-source technologies used for everything from Web servers, to databases, to operating systems for mobile devices. Although cost is often a factor for choosing an open-source solution over a proprietary one, most businesses aren’t just looking for a free solution when they choose open source: They’re usually also interested in the fact that open-source products are often more innovative, more secure and more agile in responding to the needs of the user community than their proprietary counterparts.

Indeed, the most successful open-source projects are built by communities based on principles of inclusion, transparency, meritocracy and an “Upstream first” development philosophy. By adhering to these principles, they can deliver significant value to both device manufacturers and service providers that transcend what’s offered by makers of proprietary platforms.

Open-source Principle No. 1: Inclusion
Inclusion, rather than exclusion, has always been a key tenet of open source. The idea is simple: No matter how many smart people your company employs, there are many, many other smart people in the world -- wouldn’t it be great if you could get them to contribute to your project? Successful open-source projects realize that contributions can come from anywhere and everywhere. By harnessing the capabilities of a larger community, open-source developers can deliver solutions that are often superior to proprietary ones. Contributions range from writing and debugging source code to testing new releases, writing documentation, translating software into another language or helping other uses.

Open-source Principle No. 2: Transparency
For a community development effort to work, members of the community need transparency. They need to know what’s happening at all times. By putting forums in place to encourage public discussions such as mailing lists and IRC, creating open-access problem-tracking databases using tools like Bugzilla and building systems for soliciting requests for new features, open-source developers develop a culture of trust that embraces transparency and tears down barriers -- which can stifle innovation -- between contributors.

For device manufacturers and service providers, this transparency translates directly into their ability to improve their own time-to-market and compete on a level playing field. The “Release early, release often” philosophy that frequently accompanies a transparent culture means they can evaluate new features earlier in the development cycle than they can with proprietary products. They can also provide feedback in time to influence the final release of a product.

In contrast, when a developer withholds source code until final release, those involved in the development process have a built-in time-to-market advantage over those without early access.

Open-source Principle No. 3: Meritocracy
Unlike the hierarchy of a traditional technology firm, the open-source community is one based on merit. Contributors to an open-source product prove themselves through the quality and quantity of their contributions. As their reputation for doing good work grows, so does their influence. This merit-based reward system creates much more stable development environments than those based on seniority, academic pedigree or political connections.

The Linux kernel is probably the best-known open-source project and operates on the principle of meritocracy. Linus Torvalds, founder of the Linux project, and a number of other maintainers coordinate the efforts of thousands of developers to create and test new releases of the Linux kernel. The Linux maintainers have achieved that status as a result of proven contributions to the project over a number of years. Although many of the key Linux maintainers are employed by major corporations, such as Intel and Red Hat, their status is a result of their contribution -- not their company affiliation.

Open-source Principle No. 4: “Upstream First” Philosophy
Finally, open-source developers who take advantage of existing open-source software projects rather than adopting a “Not invented here” attitude tend to be innovation leaders, especially in the fastest-paced markets.

While it is sometimes tempting to simply take source code from a project and modify it for your needs, without worrying about whether or not the original (upstream) project will accept your modifications, this approach typically leads to suboptimal results. First, you will be stuck maintaining this forked version of the project for as long as you need to use it. Second, if everyone adopted this approach, the upstream project would not benefit from the improvements made by others, which defeats one of the key benefits of open source.

So, the most successful projects that rely on components from other upstream projects have adopted an “Upstream first” philosophy, which means that the primary goal is to get the upstream project to adopt any modifications you have made to their source code. With this approach, your platform and other derivative (downstream) projects benefit from those upstream enhancements, and the platform does not incur the maintenance expense associated with maintaining a branched version of the upstream project.

Tips for Building and Deploying Cloud-based Apps

The cloud and cloud-based solutions are here to stay. Recent IDC research shows that worldwide revenue from public IT cloud services exceeded $16 billion in 2009 and is forecasted to reach $55.5 billion in 2014. Clearly, the pace of growth is quite staggering.

Companies of every size and stripe are leveraging the cloud to outsource noncore competencies, improve efficiencies, cut costs and drive productivity. Central to every company’s cloud strategy is determining how best to build and deploy cloud-based applications.

Here are a few best practices to help you make the process of building and deploying applications as straightforward as possible.

1. Design your applications for performance and scalability.
Building cloud-based applications is vastly different from building on-premise ones, so you need to design your applications to maximize their ability to benefit from the cloud’s elastic computing nature. The most obvious way to do this is to create stateless apps because they scale better.

Many thought leaders believe that the stateless model facilitates much greater scalability than conventional computing and combines effectively with virtualization to achieve optimum data-center utilization.

2. Build upon existing assets.                                 
For companies seeking to maximize the value and efficiency of their cloud applications, the best approach is to build upon existing assets rather than start from scratch. Existing assets offer various benefits: First, they can be shared and reused, often more quickly and smoothly than new ones. Second, IT users have some degree of comfort using them. And the bottom-line justification: They are probably paid for.

An existing asset, such as a mobile sales app, can be repurposed and tweaked to create a new cloud-based app in a foreign language for a field sales force.

Software as a Service (SaaS) applications are a good choice for such sharing and reuse as they enable business users to collaborate, create and share assets quickly and easily.

3. Determine the right amount of isolation and sharing of assets.
The flip side of sharing is isolation. Some assets need to be shared by all users, while others need to be restricted to certain users due to their confidential or sensitive nature. At the same time, it is desirable to create multi-tenancy collaborations so that users in different groups of your company can develop and share information and assets that will enhance the productivity of all tenants.

4. Don’t ignore taxonomy and governance procedures for your assets.
Categorizing and defining your assets is vital -- especially if you work in an enterprise or even global company with hundreds or thousands of assets in different countries and dozens of languages. Besides including the most obvious assets -- such as applications, operating systems and network platforms -- you should add such intellectual assets as designs, implementation documents and even marketing information.

To make your life as easy as possible, consider detailing attributes for your assets so you can search for them effortlessly. For example, label your assets by vertical markets (such as finance and manufacturing) and level of adoption (such as mature, advanced and beginner).

You might also want to specify roles for people handling those assets. Think: creators, managers, users and those who can modify and share assets with others.

5. Allay your security worries before committing to a vendor.
Putting your data and apps in the cloud is fraught with security risks. Top-of-mind concerns for most companies are: data integrity, data location, data recovery, regulatory compliance, and privacy. The overarching concern is “Will my data be safe?” Before committing to a cloud vendor, consider getting a neutral third-party to do a thorough security assessment of the vendor. Companies should also conduct their own high-level audits of a vendor’s security and ask the vendor for proof of its security claims.

Taming the Parallel Beast

Many programmers seem to think parallelism is hard. A quick Internet search will yield numerous blogs commenting on the difficulty of writing parallel programs (or parallelizing existing serial code). There do seem to be many challenges for novices. Here’s a representative list:

  • Finding the parallelism. This can be difficult because when we tune code for serial performance, we often use memory in ways that limit the available parallelism. Simple fixes for serial performance often complicate the original algorithm and hide the parallelism that is present.
  • Avoiding the bugs. Certainly, there is a class of bugs such as data races, deadlocks, and other synchronization problems that affect parallel programs, and which serial programs don’t have. And in some senses they are worse, because timing-sensitive bugs are often hard to reproduce -- especially in a debugger.
  • Tuning performance. Serial programmers have to worry about granularity, throughput, cache size, memory bandwidth, and memory locality. But for parallel programs, the programmer also has to consider the parallel overheads and unique problems, like false sharing of cache lines.
  • Ensuring future proofing. Serial programmers don’t worry whether the code they are writing will run well on next year’s processors -- it’s the job of the processor companies to maintain upward compatibility. But parallel programmers need to think about how their code will run on a wide range of machines, including machines with two, four, or even more processors. Software that is tuned for today’s quad-core processors may still be running unchanged on future 16-, 32- or even 64-core machines.
  • Using modern programming methods. Object-oriented programming makes it much less obvious where the program is spending its time.
  • Other reasons that parallel programming is considered hard include the complexity of the effort, insufficient help for developers unfamiliar with the techniques, and a lack of tools for dealing with parallel code. When adding parallelism to existing code, it can also be difficult to make all the changes needed to add parallelism all at once, and to ensure that there is enough testing to eliminate timing-sensitive bugs.

Use Serial Modeling to Evolve Serial Code to Parallel
The key to success in introducing parallelism is to rely on a well-proven programming method called serial modeling. Using serial modeling tools and technique, programmers can achieve parallelization with enhanced performance and without synchronization issues. The essence of the method involves consistently checking and resolving problems, and beginning early in the process to slowly evolve the code from pure serial, to serial but capable of being run in parallel, to truly parallel.

The first step is to measure where the application spends time -- effort spent in hot areas will be effective, while effort spent elsewhere is wasted. The next step is to use a serial modeling tool to evaluate opportunities for potential parallelization and determining what would happen if this code ran in parallel. This kind of tool observes the execution of the program, and uses the serial behavior to predict the performance and bugs that might occur if the program actually executed in parallel.

Checking for problems early in the evolution process, while a program is still serial, ensures that you don’t waste time on parallelization efforts that are doomed because of poor performance. You can then model parallelizations that resolve the performance issues or, if no alternatives are practical, focus your efforts on more profitable locations.

The tool can also model the correctness of the theoretical parallel program, and detect race conditions and other synchronization errors while still running the serial program. Although the program still runs serially, it is easy to debug and test, and it computes the same results. The programmer can change the program to resolve the potential races, and after each change, the program remains a serial program (with annotations) and can be tested and debugged using normal processes.

When the program has fully evolved, the result is a correct serial program with annotations describing a parallelization with known good performance and no synchronization issues. The final step in the process is to convert those annotations to parallel code. After conversion, the parallel program can undergo final tuning and debugging with the other tools. The beast has been tamed.


Photo: @iStockphoto.com/angelhell

11 Tips for Mobile Software Development

More than 99 million smartphones shipped in just the first quarter of this year, says analyst firm IDC. Many of them are winding up in the hands of business users, including your employees and business partners. That trend means, sooner or later, you’ll have to develop smartphone apps. Here are 11 tips:

1. Track market shares.
It’s critical to keep up with trends in smartphone platforms, where the only constant is change. Sure, BlackBerry has long been synonymous with business, but it now lags both Android and Apple’s iOS in the race for market share, which affects what your company uses. In fact, Android is a case study in how quickly a platform’s fortunes can change: Between late 2009 and late 2010, Android’s market share grew 615 percent -- enough to leapfrog into first place, says analyst firm Canalys.

MeeGo and Windows Mobile are two other platforms to monitor. And don’t overlook Symbian, especially if your company has a lot of employees based outside of North America.

2. Learn the language.
Platform companies try to build market share by using programming languages and equipment that developers already know. For example, Windows Mobile lets developers reuse their existing Visual Studio and .NET development skills and server infrastructure to extend their applications to mobile devices. Meanwhile, iOS requires Objective-C development. Partnerships and outsourcing are two ways to develop for platforms that use unfamiliar languages.

3. Develop for multiple platforms.
Cross-platforming requires time and resources, but it ensures that your app’s fate isn’t tied to a single platform. One obvious way is by creating a separate app for each platform. But some developers say it can be cheaper, easier and faster to use CSS to recode Web apps to fit small screens, and then use JavaScript to control the events. The downside is that you might lose access to some of the device’s features, such as an accelerometer.

4. Look beyond smartphones.
Android and iOS now run on tablets too. The good news is that apps originally developed for smartphones can typically run on tablets without modification. But be aware that tablet users increasingly expect developers to create versions that take advantage of their devices’ larger screens and often faster processors. So identify tablet-specific features and leverage those when developing a tablet-only version of your app.

5. Strive for consistency.
It can be challenging to develop an app so it has the same look and feel across all Android or BlackBerry devices, let alone across multiple platforms or across both smartphones and tablets. But it’s still a goal worth pursuing, because most enterprises have a mix of devices. For starters, create a database of all of your company’s approved devices and their features -- particularly screen size, resolution and aspect ratio -- and whether they have a physical or virtual keyboard. Then, design your app to ensure that every function provides at least a basic, user-friendly experience for each device’s user group.

6. Identify integration needs.
If your app needs to tap into another system, such as your company’s CRM and other back-office systems, it’s never too early to figure out how your app will get that access. Just as important, ensure that it gets access in a way that doesn’t leave data in the open and doesn’t create back doors for hackers. Once you’ve got a beta app, test it to verify that the integration works.

7. Don’t hog the CPU and memory.
Sure, many of today’s smartphones have 1 GHz or faster processors and are connected to networks with speeds north of 1 Mbps. But many don’t, so it’s important to develop apps that provide a good user experience even on midrange handsets and older, slower networks. Most of today’s mobile platforms now support some level of multitasking, meaning your app will likely compete with several others for processing, memory and battery power. But be aware that no two platforms support multitasking quite the same way. For example, check whether a platform allows your app to do everything you need it to when it’s running in the background.

8. Be aware of carrier restrictions.
Wireless carriers have the power to block apps, such as those that compete with their fee-based services, or use what they deem as excessive amounts of bandwidth. Learn about these concerns and respect them rather than trying to do an end run. Be aware that even low-bandwidth apps can clog up cellular networks -- and sap batteries -- by constantly generating unnecessary signaling traffic. For example, an overly chatty IM app almost single-handedly crashed T-Mobile’s network in 2009.

9. Respect enterprise concerns.
Design apps so they use bandwidth sparingly, which helps users stay under their rate plan’s monthly usage cap and avoids the need for putting all mobile employees on a pricey unlimited-use plan. Bandwidth efficiency also helps extend battery life. Ideally, your app should not be the reason why a tablet or smartphone can’t go an entire workday before it needs charging.

10. Register with app stores and developer networks.
Registering with developer networks gets you access to their SDKs, while registering as a publisher ensures you get paid. Even if you’re outsourcing development, you can still register as the publisher so you can manage the sales revenue.

11. Certify.
Some app stores require certification, a process that includes vetting at both the platform and network usage levels. Certification often takes longer than developers expect, so don’t build your business model around the assumption that your app will be ready for employees the day after it’s finished.