Speeds and Feeds

Listen carefully. I am about to reveal one of the great apparent secrets of the microprocessor industry. This secret largely determines whether new products succeed or fail.

I don't know why it seems to be a secret. It's simple enough. I figured it out early, in my first job in the industry, and I've seen it demonstrated over and over since then. I'm hardly the only one who knows this secret; I've seen dozens of talks that allude to it, and a few that mentioned it specifically. I've talked about it myself in articles I wrote for Microprocessor Report and other publications.

Unfortunately, I've also seen hundreds of products brought to market in apparent ignorance of this simple rule, and they've all failed, wasting the billions of dollars invested in their development. Assuming the developers weren't throwing away their money on purpose, I conclude they must not have known the one basic fact that doomed their projects, which means it must be a secret.

The secret is...... Read more

In a corporate blog post this week, Microsoft Vice President Horacio Gutierrez promoted the idea of a "harmonized, global patent system," in which all the nations adopt common standards for processing and approving patent applications.

Properly done, patents approved in one country could become enforceable in other countries, as is the case with copyrights under the terms of the Berne Convention.

I really have no problem with harmonization if it is properly done, but I think it would be tremendously difficult to achieve good results. The reality of patent protection is radically different from that of copyrights because patents are allowed based on the merits of the application; someone has to make a judgment call.

Would nations be able to compete for patenting fees on the basis of their approval rate? After all, who could say whether I invented a new audio calibration standard here in Cupertino--or Costa Rica, if I just happened to visit a patent agent while on holiday there? Even if this wasn't allowed, I expect all nations would begin to relax their standards in order to give their local inventors an edge in the global marketplace--a classic "race to the bottom."

Or would there be just one international patent bureau, perhaps run as an agency of the United Nations? I shudder to think how that would turn out, with the General Assembly dominated by smaller nations with little vested interest in patent protection.

Unfortunately, Gutierrez takes the latter position:

In today's world of universal connectivity, global business and collaborative innovation, it is time for a world patent that is derived from a single patent application, examined and prosecuted by a single examining authority and litigated before a single judicial body.

Not only does he want an international patent bureau, he wants to create a new international court system with global enforcement powers. The potential for abuse here is truly staggering.

But as objectionable as I find that proposal, my real issue with Gutierrez's post is that it's completely irrelevant to the real problems with the worldwide patent system.

Gutierrez summarizes:

Big challenges certainly confront the global patent system: Escalating patent application backlogs; lengthening pendency periods; increasing costs of patent prosecution; dubious patent quality due to the global explosion of prior art and the time allowed to examine applications; and examination inefficiency due to duplication of work by multiple offices.

Removing the duplication would help a little. About half of U.S. patents go to non-resident inventors. That fraction is increasing, and it's already larger in most other countries because of the stronger emphasis on innovation in U.S. companies. Letting inventors go through the process just once, in their own countries, would eliminate the duplication. But again, I think this approach would create more problems than it solves.

In any event, a factor of two here or there is not going to solve the fundamental problem of patent quality. The high percentage of bad patents in the system--and believe me, I can personally testify to how many bad patents are out there--undermines the whole system.

I've been thinking about this problem for over 20 years now, and I have some suggestions:

Problem statements. All patent applications should include a statement of the specific problem(s) the claimed invention is intended to solve. These problem statements should be published immediately and anonymously, along with whatever prior-art references have been disclosed--but no details of the invention itself. The problem statements and prior-art references would be taken as narrowing the scope of the invention. The public would then be free to point to known solutions, or even submit new ones, which would create a presumption of obviousness if they happen to coincide with the filed claims.

Claim standardization. One social benefit of the patent system is to publish inventions so that others may use them, either immediately if a license is made available, or after the patent expires. A published patent may also serve as the foundation of further inventive work. But patents are difficult for humans to understand and are practically immune to reliable machine analysis and searching. I think patent claims should use a standardized grammar and vocabulary that eliminates ambiguity and precisely identifies the scope of the invention. Although defining these new standards would be a difficult and lengthy process, the rewards would be tremendous.

Examination fees. As an inventor myself it pains me to say this, but examination fees must cover the actual costs of examination. That means charging enough to let the patent office hire enough qualified examiners to handle applications as quickly as they come in, rather than letting a backlog develop. Published problem statements and standardized claims will help a lot, higher fees may cut down on bogus patent filings, and we'd all like to see the patent office managed better. But ultimately, the system has to support itself.

No triple damages. U.S. law provides for triple damages when someone "knowingly, deliberately, intentionally, willfully, or wantonly" infringes a patent. But these damages are routinely awarded whenever there is evidence that an infringer was aware of a patent, even if the knowledge played no role in product development or there was truly some reasonable disagreement as to whether the patent was relevant. As a result, this law discourages study of existing patents, which is directly contrary to the constitutional purpose of the patent system. Knowledge alone is not a bad thing; we shouldn't penalize it.

I'm sure there are many other good ideas out there for improving the U.S. patent system. We need to talk about them, and we need to find solutions to our own problems before we even start thinking about globalization.

Much has been made lately about the trend toward solid-state drives. Now a new Intel technology, code-named Braidwood, may delay that trend, blending the performance of solid-state drives with the economy of old-style hard drives.

Braidwood--like its predecessor, Intel's Turbo Memory technology (formerly code-named Robson)--is basically a solid-state cache for all the disks in the system.

I heard about Braidwood earlier this summer on CNET (see "Intel 'Braidwood' chip targets snappier software" by Brooke Crothers). But I shrugged it off, assuming it would be no better than Turbo Memory, which left a bad taste in the mouth of many PC makers, end users, and Microsoft execs. Turbo Memory (and Turbo Memory 2.0) wasn't cheap, and it definitely wasn't worth the cost. The PC industry operates on such slim margins that every dollar's worth of hardware has to earn its keep--and Robson didn't.

But then I read an EE Times article this week by Mark LePedus describing a new report from Jim Handy of analyst firm Objective Analysis.

The 62-page report is titled "Intel's Braidwood: Death to SSDs?"

Handy's report argues persuasively that Braidwood might actually be worthwhile, and that got my attention. I've known him a long time, and he's a very good analyst--he's been covering memory and caching technology a lot longer than I have. He wrote one of the standard references for computer system architects, "The Cache Memory Book."

So I sent Handy a note, and he sent me a copy of the report. And now that I've read it, I'm inclined to agree with his conclusions, assuming the information he's obtained about Braidwood is accurate. It does seem reasonable, at least.

The first thing to understand is why flash memory can be a good disk cache. This boils down to its much faster access times: microseconds, not milliseconds. Flash can actually take much longer to write than a hard disk. But for reads, it's really quick. So if you can be smart about putting the right hard-disk data in the cache, especially by choosing the right time to do those write operations, you can save huge amounts of time on future disk reads.

... Read more

Apple's Snow Leopard operating system, which hits the streets on Friday, has plenty of new technology--but one of its major new features will soon be available on Microsoft Windows, Linux, and other major platforms.

OpenCL, the Open Computing Language, was originally proposed by Apple to support parallel programming on GPUs. There are other GPU programming languages, such as Nvidia's CUDA (Compute Unified Device Architecture) extensions for C and the Brook stream program language developed at Stanford University and included in Advanced Micro Devices' Stream Computing software development kit, but rather than choosing one of these languages, Apple chose to create a new standard independent of the big graphics vendors.

In fact, OpenCL is even independent of Apple. One of the first things Apple did was offer to hand it over to the Khronos Group, the same independent standards organization that manages the OpenGL standard for 3D rendering.

Supporters of the OpenCL standards effort at the Khronos Group include the biggest CPU and GPU makers in the industry. Apple is also involved but not shown here.

The members of the OpenCL working group turned Apple's draft specification into the released version 1.0 spec in just six months (see Brooke Crothers' "OpenCL goes beyond Apple" from last December)--and in the process, it created what may be the best solution so far to the general problem of parallel programming.

See, OpenCL isn't just for GPUs. It was designed from the beginning to get the most out of multicore processors too. After all, if you have a multicore CPU--and you probably do--why let it go to waste? OpenCL is flexible enough to support both CPU-optimized and GPU-optimized code, and smart enough to choose the right code, depending on what hardware is available in the system to run it. Most of the competing parallel-programming languages can't do that.

OpenCL can take advantage of both task-level parallelism (running many tasks at once, whether different tasks or copies of the same task) and data-level parallelism (where a single instruction within a task is applied to multiple data items at once--also known as SIMD). Some parallel-programming languages can't do that, either.

But OpenCL's biggest advantage isn't technical in nature: it's that no other parallel-programming language will be so widely supported. The support starts with Snow Leopard but will go well beyond that. AMD and Nvidia will have OpenCL drivers for their GPUs under Windows and Linux. AMD and Intel will support OpenCL on their CPUs (including Intel's Larrabee). And AMD has already shipped its first OpenCL implementation for its Athlon and Opteron processors.

Implementations for video game consoles and DSPs (digital signal processors) are also under development. I've even heard that future releases of OpenCL may be able to work with less common hardware, such as FPGAs (field-programmable gate arrays).

We had an excellent half-day OpenCL tutorial last weekend at Hot Chips 21. There were also some great OpenCL presentations at Siggraph 2009 earlier this month; if you'd like more detailed information, that's a good place to start.

All this support for OpenCL means that it should become the first choice of academic and commercial developers who want a good cross-platform way to develop parallel code. Expect to see OpenCL used in software for audio and video processing, cryptography, medical imaging, and many other applications--including, of course, gaming.

(Disclosure: I will be writing a technical white paper for Nvidia, one of the companies covered in this story.)

Google is developing an operating system of its own, based on the company's Chrome browser and intended primarily for use in low-cost Netbooks. Now I'll tell you why I think Google is doing it.

Like any other commercial enterprise, Google is trying to make money. No secret there. But Google doesn't make money the way other computer software companies do.

(Credit: Google)

Microsoft, for example, makes money mostly by selling software (and a few hardware products) to computer users. There are two sides to this plan. Microsoft wants to make computers more valuable, so buyers will spend more of their income on computers; and it wants to increase the share it receives of that budget.

What makes Google unusual is that it wants a share of a different budget: the time people spend in front of their computers. Google makes money by displaying ads on a small part of the display while people view Internet content on the rest. Not all the time, of course, but the opportunity is there, and Google's multibillion-dollar revenue shows how well this strategy can work.

Turning the Chrome browser into the Chrome OS is technically straightforward, though of course it'll take a lot of work. A browser already has most of the key elements of any OS: application programming interfaces (APIs) to allow application software to display content and accept user input, store and retrieve data from mass storage, communicate over the Internet, and so on. Google will have to add a driver model and some other things that don't exist in a browser, but it can learn from how these things are done in existing operating systems, and possibly even borrow much of the code directly from Linux; there's no need to reinvent the wheel.

Existing operating systems such as Windows support a far wider variety of programming languages and provide far more services than Chrome OS will, but Chrome will probably be plenty good enough for Netbooks. (Personally, I don't think Netbooks are good for much, and many Netbook buyers seem to agree as shown by the huge volume of refurbished systems now available from remarketers like Woot.com.)

So, Google is after your time, not your money. It can try to get more of your time in the same ways Microsoft tries to get more of your money. Will the Chrome OS increase the time people spend in front of the computer? No, quite the opposite. There will inevitably be less to do on a Chrome OS computer than on a Mac or Windows machine. Buying a Chrome-based Netbook means giving up the chance to run most Windows games, Apple's iLife suite, and other popular software.

But for Google, the key is this: once you've got a Chrome system, Google's in charge of ALL the time you spend with it.

I don't think that's good enough, and it looks like Google feels the same way; the company intends to implement the whole Chrome OS environment within the Chrome browser so Linux, Mac and Windows users can also run Chrome applications. This plan is necessary, since Google can't very well hope to muscle aside the incumbents, but it means that Netbook buyers will have no reason to prefer a Chrome-based machine.

Or will they? Linux may be free, but Google can undercut that price if it's willing to cut OEMs in on its ad revenue. In this way, Google could bring to market a subsidized pricing model we usually associate only with 3G-equipped notebooks. Google won't have nearly as much money to throw around as the cell phone operators do--maybe just a few unpredictable dollars per month averaged across all Chrome OS users vs. the reliable $60/month subscription fees associated with 3G cards--but that could still add up. Even a $20 subsidy could amount to 10 percent of the sale price of a cheap Netbook, which could tip the balance in favor of Chrome.

Like I said, it seems to me that Netbooks aren't the ideal platform for this strategy. The Google model can't work as well on a small screen, since users will be reluctant to share what little space they have with Google's ads. But they'll work well enough, and Google has no realistic chance to place Chrome on mainstream notebook and desktop systems except in the same narrow markets where Linux sells today. (And not all of those; for example, Chrome has no shot at the engineering workstation market, where Linux is popular.)

So I'm sure we'll see some number of Chrome OS-based machines on the market in 2010, and then we'll see what happens. My guess is that Chrome will do about as well as Linux has done in the Netbook business: not well. A lot of people will try it, possibly enticed by those lightly subsidized prices and the usual interest in novel computing platforms (the information-technology equivalent of the Coolidge effect, which perhaps could be known as the Glaskowsky effect.)

And then most of those people will return those machines, or give them to their ungrateful children, or just toss them onto a shelf to gather dust, and they won't buy more of the same--at least not until Google spends a few more years building Chrome OS into a fully competitive product, which I'm sure it will do. Google's big enough, and it knows there's a business here. It just won't be ready to take full advantage of the opportunity just yet.

Dean Takahashi sent me an e-mail pointing to a piece he wrote on VentureBeat describing statements Wednesday by Intel's Chief Technical Officer Justin Rattner targeted at NVIDIA. CNET's own Brooke Crothers covered the same story and provides additional background here.

Intel Chief Technology Officer Justin R. Rattner

(Credit: Intel)

The technology at issue relates to 3D graphics for PCs. All current PC graphics chips use what's called polygon-order rendering. All of the polygons that make up the objects to be displayed are processed one at a time. The graphics chip figures out where each polygon should appear on the screen and how much of it will be visible or obstructed by other polygons.

Ray tracing achieves similar results by working through each pixel on the screen, firing off a "ray" (like a backward ray of light) that bounces off the polygons until it reaches a light source in the scene. Ray tracing produces natural lighting effects but takes a lot more work.

(That's the short version, anyway. For more details, you could dig up a copy of my 1997 book Beyond Conventional 3D. Alas, the book is long since out of print.)

Ray tracing is easily implemented in software on a general-purpose CPU, and indeed, most of the computer graphics you see in movies and TV commercials are generated this way, using rooms full of PCs or blade-server systems.

Naturally, Intel loves ray tracing, and there are people at Intel working to ... Read more

It's been a big week for small systems.

On May 29, VIA formally announced (here) its "Nano" family of low-power x86 processors. These chips will be especially valuable in small laptops, UMPCs, and so-called mobile Internet devices (MIDs).

Then on June 2, NVIDIA announced (here) its Tegra 600 family, which is also being marketed for MIDs. But Tegra is a very different animal. It's based on an ARM11 processor core, which can run Windows Mobile or Linux but not Windows XP or Vista.

VIA's Nano processor. The chip itself, the silver rectangle in the center, is about 7.7mm x 8.3mm.

(Credit: Courtesy of VIA Technologies, Inc.)

VIA's Nano processors are based on a new microarchitecture that is a giant step beyond previous VIA products and not far behind that of competing parts from AMD and Intel. Unfortunately, in this business, third place isn't a good place to be. VIA's older processors sold in relatively small quantities for low prices. Fortunately, they were very small and thus economical to make and sell.

The new Nano family offers much higher performance, with clock speeds from 1.0 to 1.8 GHz... but it's difficult to know what these clock speeds mean by comparison with AMD's or Intel's, and VIA isn't telling us, at least not directly. In this white paper on the Nano family, VIA only compares the performance of the new chips to its older C7 series.

But VIA does publish some numbers, so I was able to make some comparisons.

Take, for example, the Nano L2100 at 1.8 GHz vs. AMD's 2005-vintage Turion 64 ML-34 at the same speed, as found in the famous Acer Ferrari 4000 (reviewed here by PC World). The single-core ML-34 was much faster despite the clock-speed parity:

Of course, the ML-34 consumes much more power than VIA's processor; the ML-34 has a 35W TDP (thermal design power) specification, whereas the L2100 has a 25W TDP. The L2100 idles at a mere 500mW, but the ML-34 probably consumes at least ten times as much when idle.

To be fair, I'm not sure these are entirely fair comparisons, since VIA didn't publish the details of their system configuration. Also, VIA's performance position probably looks better on simple productivity applications, but I prefer to look at multimedia performance since that's what we usually find ourselves waiting on. It's been a while since we had to worry about out-typing our word processor...

I'm looking forward to seeing some good performance and power figures for Intel's Atom; I think the VIA chips will turn out to be effectively faster but run a little hotter. When I get more data, I'll post a comparison.

But considering that the Nano is generally 60% to 200% faster than the C7 and much more power-efficient than competing products from AMD and Intel, the new product family will likely improve VIA's market position significantly over the next year.

NVIDIA's Tegra, a high-integration processor for handheld gizmos such as mobile Internet devices.

(Credit: Courtesy NVIDIA Corporation)

NVIDIA's Tegra, on the other hand, offers no compatibility with existing PC systems or software, and its performance isn't even in the same class. The Tegra 600 family's ARM11 processor core runs at a maximum speed of 800MHz and, because it's a much simpler design, it offers a fraction of the effective performance of VIA's Nano.

So how can it possibly compete with Nano in mobile Internet devices?

Well, one answer is that Tegra is meant to deliver a much more complete solution with much lower power consumption. Instead of being just a core on a chip, like the Nano family, the Tegra 600 and 650 consist of a CPU core, a GeForce GPU, special-purpose hardware for accelerating digital video decoding and camera functions, and a dual-display controller that supports HDMI, LCDs, CRTs, and NTSC/PAL video. All of that on a chip the size of a dime, as you can see in the photo.

But the real answer is that what NVIDIA means by "mobile Internet devices" is different than what Intel (which coined the phrase), AMD, and VIA mean by it.

What NVIDIA means is basically any device with a size somewhere between that of a smartphone and a laptop, which can be used to access the Internet. But this doesn't strike me as a very useful definition; it boils down to encompassing anything like a smartphone with a larger screen. It's one thing to claim the Tegra 600 family supports a "full Internet experience" as NVIDIA did in advance briefings last month, but with the wide variety of sophisticated Web 2.0 websites out there, it really takes a PC-compatible system to deliver that experience.

Now, there's no doubt that the Tegra 600 and 650 will enable fun and interesting gizmos for people who buy lots of gizmos. (And honestly, I'm exactly that kind of person.) But I believe most people are not going to be interested in them. Anything larger than a cellphone is too big to carry around all the time. Anything with a screen smaller than about 7" to 9" isn't big enough for comfortable web browsing and movie watching. Anything with a screen that large might as well be a full Windows-compatible system.

Now, over time, these segments will inevitably blur together. Moore's Law will let us squeeze more performance into handheld devices. Software technologies like Adobe's Flash and Microsoft's Silverlight will allow more websites to work on simpler systems. Hardware like high-resolution LCDs and OLEDs and tiny projection displays will help solve size problems too.

But for now, I believe the Tegra 600 family is aimed at a market segment that isn't ready to develop, whereas VIA's Nano has a big market ready and waiting for it. The Nano won't sell as well as competing PC processors from AMD and Intel, but it should help raise awareness of VIA among PC buyers and encourage PC makers to keep pushing more functionality into smaller packages.

As has been widely reported (for example, by EDN Magazine and both Brooke Crothers and Dan Ackerman here at CNET), Intel has delayed the first customer shipments (FCS) of its "Montevina" chipsets, part of the new Centrino 2 platform.

The delays are pretty short, however... a matter of just a few weeks.

Intel attributes the delays to two independent problems: one with FCC certification of the 802.11n WiFi feature in the chips (just "paperwork," Intel says), and one with the integrated graphics engines in some models.

Intel's probably right about the WiFi certification problem. I've been through the FCC certification process (for electromagnetic interference (EMI), at least); there sure is a lot of paperwork involved.

For the graphics problem, I see a couple of possible explanations.

Intel could have discovered a design flaw in the first production units severe enough to prevent them from being shipped, which would have caused a substantial delay while a new run of production units was completed. (See my earlier blog post, "Design flaws, defects, and faults", for an explanation of how design flaws are related to product defects and faults.) This delay would have been largely hidden by the usual rounds of testing, but perhaps it just used up a little more time than the slack that was available in the schedule.

Or perhaps there was a design or manufacturing flaw that didn't require trashing the first production run, but which did require some additional testing and qualification to reject specific problematic parts. This could be caused by slower or hotter operation than expected, for example. Such a problem would cause a shorter delay-- just the extra testing time. A statement from Intel in the Crothers post referring to "re-screening" suggests this is the situation here, although potentially that statement could also describe testing a second production run to ensure the problem has been solved.

I find it interesting that this problem is related to Intel's new graphics engine, which is certainly the most important element of the new chipset. Intel's previous integrated graphics products have been criticized for not really being up to the challenges of running Windows Vista, including by Microsoft itself, but due to pressure from Intel, Microsoft certified these chips as "Vista Capable." That's technically true-- I've used integrated-graphics platforms under Vista myself-- but the resulting shortfalls in performance and features probably discouraged many new Vista users.

Graphics engines are very complicated, and getting more complicated every year. Intel started out well enough in the graphics business when it worked with Real3D (now defunct) to develop the Intel740, a discrete graphics chip, but 18 months later it found itself already 18 months behind ATI and NVIDIA, and fell back to selling only integrated-graphics chipsets, where the graphics component is worth only a few dollars in incremental revenue.

Intel plans to get back into the market for discrete graphics chips in 2009 or (more likely) 2010 with "Larrabee", a multi-core CPU in which some cores are optimized for graphics processing. I think Larrabee will turn out to be a technical disaster, but Intel has leveraged its market domination to turn previous technical disasters into financial windfalls. Think of the Pentium 4's "Hyper-Pipelined" design, for example, which was too hot and too inefficient, ultimately forcing Intel to bring its predecessor, the P6 design, back from the grave several years later. Intel's current graphics engines, however, are barely worth selling today, and they won't be worth reviving after Larrabee has run its course.

I've been using an Apple MacBook Pro for a little over a year now, and I'm pretty happy with it.

Apple's new Mac OS X Leopard

(Credit: Courtesy of Apple)

I didn't immediately upgrade to Leopard, the new version of Mac OS X, when it shipped back in November for reasons I discussed here, but last weekend I decided to go for it.

There's a new update coming to version 10.5.2, which according to a release note available to Apple developers includes a raft of bug fixes, but I wanted to upgrade to Microsoft Office for Mac 2008 as soon as possible, so I figured I'd just go ahead and upgrade OS X at the same time. (I'll probably post a review of Office 2008 sometime soon.)

The OS upgrade process appeared to go well, but when I tried to log in, Leopard said it wasn't able to access my home folder. I use Apple's FileVault security technology, which stores my home folder in a virtual disk image that is encrypted using the Advanced Encryption Standard (AES). FileVault protects my data if the machine is stolen, and I regard it as an indispensable feature of Mac OS X.

Unfortunately, Leopard wasn't happy with the disk image for my home folder, and simply refused to open it.

I wasn't expecting this problem, but I was prepared for it. I made a backup of the machine just before starting the upgrade, and I also maintain a secondary user account without FileVault in case of problems with the primary account. I logged into that other account and discovered on the Web that other people have seen exactly the same problem.

Apple published a tech note suggesting that this problem is related to passwords of 8 or more characters-- my passwords are all a lot longer than that, and so should yours be!-- but the complex procedure described in the note for solving the problem didn't help me.

Ultimately I had to delete and recreate my primary account then copy my files from the disk image into the new home folder. It turns out I'd have wanted to do this anyway, since Leopard introduces a new approach to FileVault that works better with Time Machine, Apple's new backup program.

Everything worked properly when I was done, but this was a slow, awkward procedure that most ordinary users would never have been able to handle. I just wish the Leopard installer had checked for this condition and done all the necessary work directly.

With Leopard running at last, I was able to get Office 2008 installed, and I'm slowly working through a number of small issues-- learning how to work around a minor bug in the new version of Apple's Mail program, upgrading some third-party software I use, etc.-- but generally I'm happy with the upgrade. Leopard seems a little faster overall, and Time Machine is great. It gives me a lot of confidence that my data is better protected against software and hardware failures.

I'm also making periodic complete backups in case I get bitten by any major new bugs in Leopard or Time Machine, but I don't expect anything like that.

I may have additional comments, especially after the 10.5.2 update... stay tuned!