On the first day of CES, I dropped by the Qualcomm booth looking for ARM-based smartbooks to try out. As I poked and prodded the Lenovo Skylight, I pulled out my Nexus One and dropped it on top of the unit for a size reference so that we could snap picture of it. As I stood there looking at the phone laying on top of the smartbook and contemplating the fact that both of these (Android-based) devices had 1GHz, ARM-based Snapdragon processors in them, I glanced across the booth and spotted an ARM-based game console sitting right next to the ARM-based iRex Iliad e-reader. And then there was the portable media player (PMP) positioned not far away... then it really sunk in: smartphone, netbook, e-reader, PMP, game console—all popular consumer electronic categories with real computing needs and a huge audience, and all on ARM right now.
Intel, in contrast, is currently in the netbook, is aiming at the smartphone, would've liked to be a game console (they had an internal team pursuing a win with the erstwhile Larrabee GPU), and has yet to signal any interest in the booming and ARM-only e-reader market (though the chipmaker does have a kind of e-reader for the blind).
My time on the show floor of CES 2010 brought home for me in a dramatic way the fact that the Intel vs. ARM war isn't really a hardware war or an instruction set architecture (ISA) war—in fact, it's not even a war at all. It's more like another fundamental turn of the wheel from fat client back to thin client—a redivision of computing labor, brought about by the ubiquity of network bandwidth, the availability of cheap wireless radios, the rise of the app store distribution model, and the cloud infrastructure build-out. But this time around, the turn has a few important twists.
Just enough cycles to run the UI
Take another look at the list of ARM-based products that I gave above: smartphone, netbook, e-reader, PMP, the Zeebo game console. None of these are content production devices. They're all networked, and they're all oriented toward messaging and/or consuming content that comes in over the wire or over the air. This fact points at the key reason that ARM processors—which aren't even in the same ballpark with x86 processors yet in terms of raw performance—have been so successful in this new "app store" and cloud-based messaging and content distribution context. Thanks to Moore's Law, ARM's inexpensive, lightweight CPU designs—not just those based on the A8, but even ARM11-powered parts like NVIDIA's Tegra—now provide enough cycles to run a rich UI. And when you have a network port on the device that lets you trade bandwidth (and some battery life) for access to massive cloud storage and computing power, enough cycles for a UI is all you really need for these new device categories.
The overall effect is that the network has made the larger computing ecosystem more efficient at division of labor, so that work gets done in the optimal location. Instead of filling in what I mean by "optimal" with a list of parameters, I'll give you two examples of this phenomenon in action.
The first, most recent example, is Android 2.1's pervasive use of voice input, a compute- and storage-intensive task that the phone can simply offload to Google's servers. There's enough network bandwidth to make the turnaround time for voice recognition fairly snappy, so that a phone would never need the local storage or cycles to do this itself.
The next example is the Crysis-on-an-iPhone demo that I saw at an AMD event last year. All of the game rendering is done by a remote server, which uses the network to push compressed frames to the phone and to take player control input from the phone. A very small local client app decompresses the frames and passes along player input—again, the phone needs just enough cycles to run the UI.
Of course, this local-remote division of labor is nothing new—it has been with us since the dawn of networking and the client-server model of computing. It's also the same phenomenon at work in the West's outsourcing of labor to developing nations via telecom infrastructure.
The twist is that on this turn of the wheel back toward the thin client model, the great bulk (by units shipped and aggregate hardware + software revenue) of the commercially available thin-client ecosystem—a growing menagerie of readers, tablets, smartphones, and other networked, special-purpose content consumption and messaging devices—will be consumer-facing. And right now, with the likely exception of Internet-connected TVs (Intel has a great shot at this), ARM has nearly the entire ecosystem locked down by virtue of the simple fact that it's the most efficient way to run a thin-client UI, and one that gives a responsive, fat-client experience without sacrificing battery life.
In sum, Intel isn't doing battle with ARM. It isn't even doing battle with the ARM ecosystem of software makers, fabs, SoC designers, and device makers. If Santa Clara is fighting anything, it's fighting the thin-client model itself. The chipmaker simply does not want the wheel to make another turn—at least, not until it's ready with an SoC that can compete in the fickle, low-margin world of consumer-facing, networked, thin-client devices. And in that respect, they're in a race against time.
Despite the fact that ARM's current advantage is entirely due to its efficiency, there is one place where a small amount of ISA lock-in may help tip the scales toward ARM in the long-run: casual games.
Cross-platform gaming: from phone to console (to tablet?)
I should admit that the introduction's implied comparison of the ARM-based Zeebo game console to Intel's Larrabee-based Playstation 4 ambitions is actually apples-to-oranges, because the Zeebo isn't intended to compete with the latest and greatest from Sony, Microsoft, or Nintendo. Rather, the company bills itself as "family fun and learning for the next billion," and its plan is to target users in the developing world by selling them a 3G-connected computer/console that runs games and educational software.
With an ARM11 core for the main application processor, an ARM9 core for audio, and a Qualcomm-designed GPU core, the console has about as much horsepower as a Nintendo DS, and less horsepower than my Cortex A8-based Nexus One. In fact, ARM11 and ARM9 are very low-performance, in-order cores, and if I were going to build such a console, my first thought would be to use an Intel processor. Atom's performance is far better than anything ARM-based on the market, and an Intel part would give you the advantages of the x86 software stack. So why didn't Zeebo use Atom?
Zeebo went with ARM and not Intel because the Zeebo is intended to run ports of an explosively popular category of casual games that people are playing right now. I'm talking about ports of smartphone games. Simply put, the ARM ecosystem gives Zeebo access to more casual games from independent and big-name studios than the PC ecosystem, and by a wide margin. During the course of a brief demo, I saw games from Activision and other studios that had been ported from their original smartphone platform at a cost to the developer of, in at least one case, as little as $50.
Ultimately, I'm not at all sold on Zeebo as a business (at close to $200, the console costs way more than a PlayStation 2), but that's not the point. The point is that there's so much money flowing into game development on the iPhone and Android that you can actually make an ARM-based game console and stock it with cheap ports. You could also stock an ARM-based iTablet with cheap ports, as well; indeed, a wave of ARM-based tablets would provide a great platform for casual games, and such tablet gaming could become a trend in itself. (At this past CES, Ars Gaming Editor Ben Kuchera was very impressed with NVIDIA's Tegra-based tablet prototypes, and wondered why the GPU maker doesn't just build and market them under its own brand. Such are ideally suited to casual gaming.)
By the time that Intel is able to squeeze the x86 ISA down into a competitive smartphone, the casual gaming market will be that much bigger, and that much harder to pry away from ARM. Of course, it's too early to tell what kind of impact that some mild ISA lock-in from games will ultimately have on the direction of the wider hardware/software ecosystem for mobiles, but I suspect it won't be trivial.
Appendix: Confessions of a cloud client skeptic
Yes, in late 2007 I was a cloud client skeptic. I had been talking to ARM and Intel about their mobile plans, and I knew that they were looking to massively increase the number compute cycles available in the handheld of 2009 and 2010. But I underestimated the network, and the fact that all of the local cycles would (at least in the near- to medium-term) go to the UI and user experience.
Interestingly enough, in the Nick Carr post that I tried to debunk, Carr was completely out to lunch with his Apple/Google collaboration speculations, but he nailed every last thing about the Chrome OS netbook. Given what we now know after the Chrome OS interview, i.e., that Google didn't really start on Chrome OS until 2009, this is a case of Carr having hit on the idea before Google did (as opposed to him having sources inside Google who tipped him off).
When thinking about the prospects for cloud clients in general and the Chrome OS netbook in specific, Carr's detailed and accurate prediction is worth noting as a data point. It's a general rule among VCs here in Silicon Valley that if an idea is a good one, there are multiple people pursuing it. The fact that Nicholas Carr and Google are both sold on the idea doesn't necessarily mean it's a good one, but that is a strike in its favor. And at this point, I'm sold on it, too.
Copyright 2016 © Godem Online Inc. | Web and server solutions by NewTech Solutions.