Looking for a Few “Eurekas”

REDMOND, Wash., Aug. 7, 2000 — Let’s say you’re a software developer who wants to make a program display information faster. How do you determine the individual steps the program takes before the image appears on the screen? The program doesn’t automatically report this information. And you can’t physically see these steps or time them with your stopwatch. Or let’s say you want to find out why a word-processing program your company developed crashes at odd times for no apparent reason. How can you sniff out the problem?

In both cases, you need a tool. Not a screwdriver, hammer or flashlight, but a software program that can understand and control other programs. These tools do much of the grunt work necessary to develop new software and improve current software. They measure how long operations take, detect and report errors, modify programs so they can run faster, and perform numerous other functions.

But tools aren’t easy to build. They can require tens of thousands of lines of computer code and take years to create. And, unlike that trusty old socket wrench with multiple ends, many of today’s tools aren’t reusable or interchangeable. Programmers often must build new ones from scratch for each new project. The extra time increases costs and dramatically slows the pace of research, contributing to the software
“bottleneck”
that researchers say is slowing advances in computers.

Microsoft Research (MSR) and the University of Washington’s (UW) Department of Computer Science & Engineering have gathered 30 top minds from various research areas to look for ways to increase the productivity and effectiveness of software developers. How? By making software tools more like those on your workbench at home: interchangeable, reusable and less costly to build.

The researchers came together this week in the Seattle area for the fifth UW/MSR Summer Institute to look for ways to overcome funding, coordination and other challenges that prevent more rapid construction of common parts, or infrastructure, for software tools.

“Thousands of these tools exist, and everybody is paying the cost over and over again to build them. Many of them could share large pieces of code,”
said Amitabh Srivastava, director of MSR’s Programmer Productivity Research Center and co-organizer of the institute.
“If common infrastructures were available, then somebody would pay the cost once. A lot of people would benefit, and the pace of research could improve tremendously.”

The institute will offer two days of lectures at the UW by top researchers, such as Monica Lam of Stanford University and Bill Griswold of the University of California at San Diego, on the use and value of infrastructure in different areas of computer research. The researchers will then gather on a small island in a remote corner of Puget Sound for informal work sessions to discuss common challenges and potential solutions.

Institutes Look to Spur Innovation

MSR and the UW hold the institutes each summer to spur innovation in some of the most exciting and challenging areas of computing. Previous topics have included biological models for computing, data mining and
“invisible”
computing.

“The institute brings together researchers from different backgrounds,”
Srivastava said.
“There are engineers who work on hardware, others who work on software and others who work on compilers. The forum allows these people to share their experiences, discuss new ideas and evaluate potential solutions.”

This year’s topic presents no end of challenges and potential rewards for software developers and researchers such as Craig Chambers, an associate professor in the UW Department of Computer Science & Engineering.

Chambers and his colleagues spent five years building an optimizing compiler, a device that allows programs to more rapidly translate computer language into the code computers use to operate.

Chambers estimates his team spent half of its time building the tools needed to do many of the compiler’s basic tasks — what he calls
“sweat work”
— such as adding code to a program for collecting performance data. If these tools had been readily available or easier to build, Chambers and his colleagues could have expanded the scope of their compiler.

“We could have been much more ambitious about the kinds of experiments we wanted to do,”
said Chambers, a co-organizer of the institute.
“But it would have been too much work for us to build all of the tools needed for the experiments. We had to pick and choose what we worked on based on what tools were feasible for us to build ourselves.”

Increasing the availability of infrastructure is one of the goals of MSR’s Programmer Productivity Research Center, created in March 1999 to investigate radical approaches for creating better software in less time.

ATOM, developed by Srivastava while he was working for Western Research Lab in Palo Alto, Calif., is an example of this kind of new approach. It is a
“meta”
tool that helps programmers build other tools and knows how and where to place testing probes into a program. It provides the reusable infrastructure needed to manipulate the binary code that computers run on.

“Before we had ATOM, a person writing a program would have to understand how to manipulate the program’s binary code,”
said Ben Zorn, an MSR senior researcher and co-organizer of the institute.
“The person would have to write 5,000, 10,000 or 20,000 lines of code. When he or she was done, you’d have a tool that could do one thing.”

More tools like ATOM are needed to help speed up and improve software development, researchers say.

“Computer hardware is incredibly fast now,”
Chambers said.
“Even if it gets twice as fast, it won’t solve the real computing problems. Software is too big, takes a long time to create and requires a huge number of people to create it. And, then, it doesn’t always work the way you want it to.”

“Building tools better and faster,”
he continued,
“provides the foundation for beginning to solve the bigger problem of creating better software.”

Infrastructure Costly to Build

So why aren’t there more ATOMs?

Infrastructure takes months or even years to create. Most universities and software companies don’t have the money or time to invest, researchers say. Much of their success — financial and academic — is determined by how fast they get software on the market or solve research challenges.

“The problem is, infrastructure doesn’t solve any problems by itself,”
Zorn explained.
“Whenever you are building an infrastructure, there is no immediate tangible result.”

Larger companies such as Microsoft have the resources to invest in infrastructure, but resources aren’t all that’s needed. Computing is changing. It is moving from programs that run on single desktop computers and mainframes to systems that distribute computing responsibilities over the Internet to numerous computers in different locations.

“The infrastructure that has been built to understand these complex distributed systems is really in its infancy in terms of the research tools that are out there,”
Zorn said.

The six-day institute may not be able to make these and other challenges go away, but organizers hope the gathering will help researchers find ways to make them less significant. For instance, to make infrastructure interchangeable and reusable, there needs to be a better understanding of the varying needs in different areas of computer research and software development. The diverse mixture of researchers at the institute should help create this understanding, organizers say.

“We want to take people who have traditionally worked separately and bring them together to talk about the infrastructure they have built,”
Zorn said.
“We also want to determine in what ways these infrastructures could be combined and what new infrastructure needs to be built.”

Stanford’s Lam wants researchers at the institute to consider more than how to construct infrastructure. She wants them to look for ways to maintain and upgrade infrastructure once it is built.

Lam and her colleagues are struggling to find funding and support to do the necessary upkeep on a compiler infrastructure they created over a four-year period with government funding.

“The success of an infrastructure goes beyond just its initial creation,”
Lam said.
“Software needs to be continually maintained, and infrastructures have to evolve. It’s not like we can build one and then live with it forever.”

Lam says government support to build the compiler was essential, but there’s no money to keep it working correctly. Many private research groups use the compiler, but none are helping to improve and expand it.

Lam hopes the institute can stir discussion on these and other issues confronting infrastructure development.
“We could use more ideas about how to go forward from here,”
she said.

Organizers downplay the chances that the institute will produce any earth-shaking breakthroughs. But Chambers expects to gain some smaller revelations.
“What I’m after as a researcher,”
he said,
“is new insights and different ways of thinking about these problems that allow me to go forward without just pounding my head harder to build more infrastructure.”

He added:

I’m hoping for a few Eurekas.

Related Posts