TechFest 2008

By Rob Knies

People all over the world use the Internet every day, to purchase goods or services, to search for information, to find diversions.

But is the World Wide Web truly worldwide?

It’s difficult to make the case. Estimates claim that approximately 70 percent of Web pages today are created in the English language, while the percentage of non-English speakers is growing faster than that of English speakers. So what if you don’t speak English? Or what if you do and you find an interesting page written in German? Or Russian? Or Chinese?

Microsoft Research aims to please.

Windows Live Translator, a free translation portal and a Web service that powers many other translation scenarios, is the result of more than eight years of diligent machine-translation effort within Microsoft Research. With it, Microsoft Research offers a simple, intuitive translation service—while making ongoing improvements to translation quality. In addition to the portal, its Bilingual Viewer features a unique, side-by-side Web-page viewer that translates entire Web pages with blinding speed between 25 sets of language pairs.

For Stephen Richardson and Heather Thorne, who are leading an effort to evangelize Microsoft Research’s machine-translation work for incorporation into a bevy of other Microsoft products and services, Windows Live Translator points the way to a future when the contents of the entire Web will be free of language-based limitations and it will be easy for users to communicate with people everywhere, from within any Microsoft product or Web service.

“This,” says Richardson, principal researcher in the Natural Language Processing (NLP) group within Microsoft Research Redmond, “is a technology that will literally change the way the world works. We’re in a place, here at Microsoft, where that can happen.”

The group’s machine-translation technology was showcased during a couple of events in early March. MIX08, Microsoft’s ongoing conversation with next-generation Web and interactive-agency professionals, scheduled in Las Vegas from March 5 to 7, featured the integration of Windows Live Translator with the upcoming version of Internet Explorer. And during TechFest 2008, an annual gathering set in Redmond on March 5-6 in which Microsoft employees and media representatives from around the world got a chance to observe and discuss the latest projects from Microsoft Research’s worldwide labs, current features and services, as well as future plans, were on display.

“Our vision,” Richardson says, “is to produce a machine-translation system and technology that can provide translation across all of the potential scenarios we can imagine, with Microsoft products and services around the world.”

It’s been a long journey for Richardson, who began working on machine translation while an undergraduate in the 1970s.

“I was a junior in college,” he recalls, “and I was on a project where we trying to create a machine-translation system that we felt would change the world. Everybody’s dream, right?

“Of course, it took a lot longer than I ever dreamt. But to be here now, involved with this great group of people putting out something that just has killer-app potential …”

Thorne, director of business strategy for the Machine Translation product team, comes to the project from an entirely different direction. Having studied Russian and International Studies during her undergraduate days, she found herself working on translation and interpretation while working for NASA on its joint space program with the Russians, and that led her to explore the state of the art of machine translation.

“Granted,” she says, “this was 15 years ago. I remember discovering that quality was quite low. It was not able to replace the need for human translators.”

For certain uses, though, this is slowly changing.

Four years ago, Thorne found her way to Microsoft, working for the Windows organization. Then she heard about Microsoft Research’s machine-translation work.

“When I discovered this team and what they were looking to do, that was a perfect fit for my background and my area of interest,” she says. “I realized that this would be a great opportunity to bring the experiences I’d had in much bigger businesses into this small team, which felt much more like a startup.”

She joined NLP in March 2007 and has played an integral role in guiding the team’s strategy toward integration of machine-translation technology into Microsoft offerings. For example, the team’s scalable Web service is being applied to address specific user scenarios, such as integration into Live Search, Internet Explorer, Windows Live Messenger, Office, and many other products and services. Users can download a widget that they can employ to add Translator to their own Web sites, and individuals can install a Windows Live Translator toolbar button for translations with a mere click. With twice the number of downloads from non-English-speaking markets compared with English-speaking markets, it’s clear that this service meets a need for international audiences.

Still, it’s been a formidable challenge to reach this point. Machine translation is a tough nut to crack. For a long time, machine translation was seen as largely unhelpful; users became frustrated with technology that often turned text in one language to gobbledygook in another.

“Machine translation had this bad reputation,” Richardson recalls, “of being unreadable sometimes.”

Perfection was proving stubbornly elusive. As it turns out, perfection itself was part of the problem.

“There was an acronym from the 1960s: FAHQT—fully automatic high-quality translation of general text,” Richardson says. “That was the holy grail of machine translation. That’s what everybody was trying for.”

FAHQT, though, turned out to be unrealistic. A couple of years ago, Jaap van der Meer, a pioneer in the translation industry, coined a new, more achievable acronym: FAUT—fully automatic useful translation. Instead of trying to devise a system robust enough to fool your school’s infallible French teacher, how about developing one sufficiently accurate to provide translations that could provide real value to real users in real time?

“What we’re trying to do is say, ‘You know, machine translation as a science is not perfect,’ “ Richardson says. “It’s far from perfect—just as search is far from perfect today. But there are a lot of things you can do to mitigate the imperfections and help customers get to the results they’re looking for.”

On one hand, there are user-interface improvements, such as the Bilingual Viewer, showing side-by-side Web-page translations that enable a user to compare a translation to the original. On the other hand, there are ways to improve the research process itself to deliver the right degree of accuracy to the right user in the right situation.

Enter MSR-MT, Microsoft Research’s machine-translation project.

MSR-MT is a data-driven machine-translation system behind Windows Live Translator that automatically acquires translation knowledge from previously human-translated text, combining linguistic knowledge and statistical processing into a hybrid approach. Using as input data millions of sentences from Microsoft technical materials that have been translated by humans, MSR-MT is capable of producing output in a single night that is on a qualitative par with systems that require months of human customization.

The system already has proven its value within Microsoft, having been used in 2003 to translate nearly 140,000 customer-support Knowledge Base articles into Spanish. The effort was extended to Japanese the next year and to French and German in 2005. Now, Microsoft’s Knowledge Base materials have been translated into nine languages by MSR-MT.

Such success has lowered the cost barrier to obtaining customized, higher-quality machine translation and is able to provide weekly updates and additions, a goal heretofore impossible to achieve. Bill Gates, Microsoft chairman, gave the mature technology the green light in 2005, and things took off from there.

“What we focused on the past year or two was to take the work we’ve used internally here at Microsoft and make it available outside the company in the most compelling initial scenario we could identify, which turned out to be Search,” Richardson says, “and then build a backbone system, a Web service that could not only supply translations to Search, but also would be the basis for anything else that we did in the future.”

The data-driven approach, Thorne adds, also enables Microsoft Research’s machine-translation efforts to focus on customer needs.

“Given that we probably can’t translate everything well,” she says, “we need to do a good job of understanding which Web sites people are looking at and what they are asking us to translate. What are the areas of the Web that people are really interested in?

“If we have limited resources and limited amounts of data we can get, where do we need to focus our efforts? It’s a combination of the technology getting better and us doing a better job of understanding the customer need.”

Such efforts, of course, require the efforts of many, as Richardson and Thorne are quick to note. Andreas Bode, the team’s development lead, has been instrumental in creating the Web-service infrastructure and leading all development. Chris Wendt, lead program manager, has worked closely with the other product teams to ensure successful integration of the Windows Live Translator Web service into their products. David Darnell has overseen the testing of the technology, and Arul Menezes and Chris Quirk were key contributors to the MSR-MT technology itself.

In addition, collaboration with the Live Search team has proved essential, and the Windows International organization has provided avid support.

“The reason why we have so many languages and gotten all the data we’ve gotten across Microsoft,” Richardson says, “is because of the effort by the internal localization community, which was spearheaded by the Windows International group.”

That team also devised the side-by-side interface that makes Windows Live Translator so easy to use. Initially, the user interface was called the Flipper Flopper. That whimsical contribution has evolved into one of the technology’s most popular features, the Bilingual Viewer.

It’s no surprise that much remains to be accomplished. New subject domains are being investigated, and product integration remains central to ongoing efforts.

“We’re always looking at improving the quality,” Richardson says, “and the more of the right kind of data that you have, and the more you do with it, the better quality you can get.”

For Thorne, it’s been an invigorating experience.

“It’s really, really exciting to be so close to a product where the people I sit next to are literally the guys who wrote the code,” she says. “It’s a very complicated space, and yet it’s still something that you can see and touch in this very tangible way. Everybody takes a lot of pride in what they do, and it’s really exciting to see the progress and to see everybody’s commitment to it.”

Richardson agrees wholeheartedly.

“We’ve always been a tight-knit group at NLP,” he says, “but our machine-translation incubation group has worked their tails off to produce something that has jumped to the forefront of what people have said is cool about machine translation. That makes me incredibly proud and grateful.”

By Rob Knies

There was a time, years ago, when computer architecture was a most exciting area to explore. Talented, young computer scientists labored on the digital frontier to devise the optimal design, structure, and implementation of computer systems. The crux of that work led directly to the PC revolution from which hundreds of millions benefit today. Computer architecture was sexy.

These days? Not so much. But Chuck Thacker aims to change that.

Thacker, a Microsoft technical fellow regarded as a pioneer in the computing industry, is working with colleague John Davis to build a hardware platform called BEE3, designed to return architecture to the cutting edge of computer-science research.

“I was in computer-architecture research for several decades and built a number of interesting computer systems,” says Thacker, who in the 1970s and early ’80s led hardware development for the Computer Science Laboratory at Xerox’s renowned Palo Alto Research Center. “But you can’t really do that anymore, because you have to design chips, and it’s just too expensive.”

In addition, simulation techniques became too slow to enable full-system experiments using real software. As time went on, interest in computer architecture began to dwindle. Those projects and papers that were devoted to the area were increasingly focused on small, incremental advances. Relevant research slowed to a crawl.

“You can count the number of people in academia today who actually do chip building,” Thacker says, “on the fingers of one hand.”

Thus, the BEE3 mission: Change the game.

BEE3, engineered by Celestica, a leading manufacturing firm, employs field-programmable gate arrays (FPGAs), semiconductors with programmable logic components, along with 64 gigabytes of DDR2 DRAM memory and a variety of high-bandwidth interfaces, all combined in a chassis that looks like a computer but is in fact a platform to emulate architectures and changes to standard architectures.

John Davis (left) and Chuck Thacker of Microsoft Research Silicon Valley collaborate on the BEE3 computer-architecture hardware platform.

“If you want to try out a new architecture or a new feature,” Thacker says, “it’s very difficult to do these days, because you have to actually build chips to build anything of substantial size. Using FPGAs, you don’t have to build chips. You can design the thing and load the FPGA with some bytes that tell it what it’s supposed to do logically.”

At that point, hardware once again begins to play a significant role in computer-architecture research.

“This is a very exciting opportunity,” says Davis, a research hardware-design engineer based, like Thacker, at Microsoft Research Silicon Valley, “especially in the academic research arena, which has been missing because it is so expensive to build chips from an actual real-cost standpoint.”

Hence, the rationale for the BEE3 project—or at least part of it.

“The project was set up for two reasons,” Thacker says. “One is to help the university community, which is one of the things we try to do a lot here in Microsoft Research. The other was that we want the machines for our own research.”

The timing is right because of the increasing maturity of FPGAs.

“They are now large enough and design tools are good enough that you can build very complex things,” Thacker states. “You can use them both for architectural experimentation and for accelerating a CPU for algorithms that don’t fit very well into [sequential] architecture.”

The viability of the FPGA approach was demonstrated last summer, when Zhangxi Tan, then an intern at Microsoft Research Silicon Valley, built a system for solving the problem of binary satisfiability, commonly used in design automation.

“He got much faster speed than what a computer could do,” Thacker reports, “because the algorithm is exactly suited for what can be done in FPGAs.”

Indeed, speed and power are the two attributes Thacker hopes the BEE3 system can help address.

“One of the big problems that we face as a company is that it’s become increasingly clear that processors aren’t going to get faster,” he says. “They dissipate too much power now, and it’s a real challenge to get rid of it. We want to look at some of these new architectures as possibilities for solving those two problems, the speed problem and the power problem.”

And Thacker and Davis have specific ideas on how BEE3 could help.

“We want to try some new techniques in internal communication within a multicore processor,” Thacker says. “In particular, we have some ideas for how to do the switch networks on such a chip and on how to use message passing as something that is available directly to programs.

“One of the nice things about these systems is that they can be very intricately instrumented, so we can get a lot of data.”

That instrumentation is an area in which Davis can help. He began working with Thacker about a year ago upon joining Microsoft Research, having developed a similar type of board as part of his Ph.D. thesis project, making him a natural to step into a project like BEE3.

“Chuck and I work together on all the aspects of the board and related gateware,” Davis says, “while interacting with our partners in terms of the prototype board manufacturing.”

The BEE3 name, incidentally, stands for the Berkeley Emulation Engine, version 3. Its predecessors, BEE and BEE2, were designed by the University of California’s Berkeley Wireless Research Center, and Thacker had used FPGAs for some projects while working at the Systems Research Center at Digital Equipment Corp before joining Microsoft Research. At the time, though, FPGAs were not sufficiently mature for the kind of architectural use BEE3 enables.

The academic connection is significant, because not only is Microsoft Research working with a variety of academic and industrial partners on BEE3, but academia also stands to be one of the prime beneficiaries. The hardware platform will be shared with academic researchers performing computer-architecture research.

“These things always go better if there are more people using them,” Thacker explains. “We decided that in order to actually benefit the way computer-architecture research is done, it would be better to just share this.”

Celestica provided the board layout and fabrication.

“The actual engineering effort … they did the schematic, the layout, the routing,” Davis says. “They’ve been a great help.”

As it turns out, there are real benefits in working with a professional hardware firm, as opposed to having the work done by academic partners.

“If you do a large-scale design like this with graduate students,” Thacker says, “you don’t get an optimal result, because it’s typically their first design. They spend a long time mastering the design tools, and they just don’t know the tricks that a professional board designer knows.

“This isn’t a matter of graduate students being dumb. They’re very smart. It’s just that, No. 1, they’re inexperienced, and No. 2, it’s not really good pedagogy, because they spend a lot of time doing the design, and as a result, they don’t have a very broad education when they graduate. I said at the beginning of the project that it was likely that the pros could get something that is half the cost and considerably more reliable in half the time, and it’s worked out that way exactly.”

Academia will, though, play a key role in BEE3’s future success. Thacker and Davis have worked closely with researchers from the University of California, Berkeley, which started the Research Accelerator for Multiple Processors (RAMP) consortium, along with the Massachusetts Institute of Technology, Stanford University, Carnegie Mellon University, the University of Texas at Austin, and the University of Washington. RAMP will provide the conduit by which BEE3 can be shared with the academic community.

“It’s six universities working together,” Davis says, “with the goal of enabling large-scale multiprocessor research.”

Other partners are contributing to BEE3, as well. Function Engineering, of Palo Alto, Calif., performed thermal modeling to ensure that the airflow in the hardware was working appropriately.

“They designed the case of the system,” Thacker says. “They designed the heat sinks for the FPGAs and did all the computational fluid-dynamic modeling to make sure that it would all work. That is one of the largest mistakes you can make in designing a computer system, to get the thermal properties wrong, because then it overheats and doesn’t work. Function was enormously helpful in this area.”

Xilinx, of San José, Calif., manufactures the FPGAs themselves, the chips and the tools to design them.

The BEE3 hardware with components labeled. The Virtex 5 LX110T components are the platform’s field-programmable gate arrays.

But Celestica has been the most significant partner in bringing BEE3 to fruition. Celestica had the design expertise. Microsoft was interested in the potential of such a hardware platform, not in providing the hardware itself.

“Celestica has reduced a lot of the complexity in terms of the actual board design and the resulting prototypes, which were fabulous,” Davis reports. “When we got them back, within a couple of days, we had test software and processors in the FPGAs up and running.”

It’s an unusual project for Celestica, Thacker notes, but the firm’s close relationship with Microsoft didn’t hurt. Celestica is a major manufacturer of Xbox 360 consoles.

“Celestica would not normally take something like this on,” Thacker observes, “because when they do engineering, they want to have a large manufacturing follow-on. But our business relationship with them is already very, very deep. They were willing to do it for us because they found it an interesting project.”

They will get the satisfaction, however, of helping ensure that BEE3 is tangible and provides immediate value.

“The system essentially works,” Thacker says. “We found one problem in the original board design and are having it redesigned, at which point we will transition it into production and we will start using it in our own research. Up until now, this has been a project in infrastructure development, not actual research, but now we can actually begin to use it.”

That prospect has Thacker and Davis enthused.

“The coolest part of this project,” Davis says, “is the board design actually is better than the devices that are on it. We’re actually able to look at signals at a higher frequency than the FPGAs are supposed to operate at, and that’s pretty exciting.

“With this platform, you’re able to validate your work and enable technology transfer from academia to industry much, much quicker. That’s a very exciting place to be.”

For Thacker, the excitement lies in the prospect of returning computer architecture to an esteemed place at the forefront of computer science.

“We want,” he says, “to revitalize computer-architecture research.”

What would software look like if it were designed from scratch with dependability and trustworthiness as the primary goal?

That’s the question Microsoft Research’s Galen Hunt, Jim Larus, and a team of colleagues asked themselves when they embarked on an ambitious research project in 2003. Five years later, they’re ready to propose an answer: It would look like Singularity, a new system-architecture and operating system built on advances in programming languages and tools.

Hunt, a principal researcher and manager of Microsoft Research Redmond’s Operating Systems Group, and Larus, a research-area manager in the Software Improvement Group, aimed to rethink system design in light of many research advances and a changed computing environment. And now that Singularity has reached a useful level of stability and functionality, they think it’s time that other researchers in academia and industry have an opportunity to build on their research.

On March 4, Microsoft Research made the Singularity source code available at no charge for academic, non-commercial use by releasing it to CodePlex, an online portal created in 2006 to foster collaborative software-development projects and to host shared source code. Hunt and Larus hope the research prototype will be used as a laboratory for experimentation and innovation, much as it has been within Microsoft Research. Over the years, more than 40 Microsoft Research researchers and interns have collaborated on the project, which incorporated their ideas on security, programming languages, tools, and operating systems—and accelerated their own research.

“Our goal was to make Singularity small enough, simple enough, and well-designed enough that you can try out radical new ideas quickly,” Hunt says. “Our thinking is that a researcher with a great new idea for improving operating systems could get from idea to published paper in under a year using Singularity.”

Rethinking 1960s-Era Design Decisions

The Singularity research project began with the idea of building more dependable software. Hunt, who specializes in operating-system development, and Larus, an expert in tools and programming languages, realized that to accomplish this, they would need better tools and a better system architecture.

The status quo that confronted them was the decades-long tradition of designing operating systems and development tools. Contemporary operating systems—including Microsoft Windows, MacOS X, Linux, and UNIX—all trace their lineage back to an operating system called Multics that originated in the mid-1960s. As a result, the researchers reasoned, current systems still are being designed using criteria from 40 years ago, when the world of computing looked much different than it does today.

“We asked ourselves: If we were going to start over, how could we make systems more reliable and robust?” Larus says. “We weren’t under the illusion that we’d make them perfect, but we wanted them to behave more predictably and remain operating longer, and we wanted people to experience fewer interruptions when using them.”

The researchers set out to design a simple, minimalist system. They were clear from the beginning that Singularity would bear no resemblance to a full-fledged operating system such as Windows, nor was it ever intended to replace Windows. They sought to create an operating system for the research environment, structured to embody the design criteria of dependability and robustness, and to demonstrate the practicality of new technologies and architectural decisions.

Technically Speaking, Singularity Is Different

Singularity differs fundamentally from other operating systems in that it is written almost entirely in an extension of C#, a modern, high-level programming language. This enables a more dependable overall computing environment because C# gives Singularity security advantages over operating systems written in lower-level languages such as C or C++. For example, by using C#, the researchers prevented a class of errors known as buffer overruns, thereby eliminating an area of vulnerability typically exploited by worms and viruses.

Singularity also incorporates three key architectural features to improve system dependability. First, Singularity pioneers the use of software-isolated processes (SIPs) to help protect programs and system services. SIPs enable programs to be broken down into components that are isolated from other software components running on the same device. This enables pieces of a system to fail without risking a total system failure. Consider this analogy: In a car, the brakes don’t fail if the radio stops working.

“In the past, creating many processes in an operating system was impractical from a cost perspective, largely because they required special support from the hardware,” Hunt says. “Rather than use hardware to build boundaries between processes, we figured out a way to build processes using a software technology called static analysis.”

Static analysis, a large and important research area at Microsoft Research, inspects a program’s source code in advance to make sure a process obeys certain rules that guarantee it’s isolated from the rest of the system. Traditionally, programs were checked at run time, using hardware mechanisms that date to the less-disciplined code of the mid-’60s.

Singularity’s second noteworthy architectural feature relates to the fact that a program’s many SIPs need to communicate and share information because they work toward shared objectives. To avoid miscommunications that can lead to errors and breakdowns, the Singularity researchers developed what they call “contract-based channels” for communications.

“We figured out how to describe the form in which communications should take place between two processes, and using static analysis, we can check the codes of the processes at compile time,” Hunt explains. “So before the code ever runs, we can confirm that the processes communicate correctly.”

Singularity’s third unique architectural feature, called “manifest-based programs,” represents another shift in orientation. Traditionally, operating systems have had no “knowledge” of a program’s composition, its purpose, or the resources it uses. Presented with a set of bits, the operating system would simply run them. Singularity, with its emphasis on overall system dependability, takes a different approach to ensure that a new program won’t “break” the programs already on board.

“We basically say, if you want to install a program to run on a Singularity system, you have to provide some information about it so we can preserve certain properties that make the system more reliable,” Larus explains. “You have to provide a manifest of the program pieces and how they fit together, and we’re going to check it. More important, we reserve the right to say ‘no.’ If a certain program doesn’t follow the rules set down for the system, you can’t install or run it.”

This ability to start with a clean slate and to retool how software is written—from the ground up—is a testament to the spirit of innovation that permeates Microsoft Research, Hunt and Larus say.

“Singularity was only possible because the environment at Microsoft Research allowed us to collect a diverse group of researchers eager to participate in a project to fundamentally rethink a basic part of everyday computing,” Larus says. “Applying everyone’s research perspectives helped us understand and demonstrate a new way to construct software systems.”