How Project Portmeirion Removes Complexity

Story by Al Riske. Photography by Howard Friedenberg.

April 28, 2009 - The story of Project Portmeirion begins over a cup of tea.

Mario Wolczko, whose name suggests his heritage (Italian mother, Ukrainian father), was born and raised in England and still buys loose leaf tea by the kilo.

Every day at 3 p.m. he brews a pot for his colleagues in Sun Labs, and on one of those occasions he and Greg Wright, who is also British, hit upon an idea.

"We had worked together for a number of years on a project that was trying to bring hardware support to the world of Java, and even though we'd come up with what we thought were interesting schemes, we were having an unsuccessful time getting the SPARC people to adopt any of it," Wolczko recalls. "The conclusion was their lives are difficult enough already. Then we come along and offer them something that has, potentially, a lot of upside, but also a lot of risk."

Exactly what they didn't need.

So, over a number of tea times, Wolczko and Wright began to talk about how they might address that problem – the increasingly complex task of designing and testing microprocessors.

Creating a competitive microprocessor requires years of work by hundreds of engineers, and it just keeps getting harder.

To illustrate the point, Wolczko plops an early SPARC manual on his desk. It's about 200 pages. The current manual comes in two volumes totally more like 2000 pages.

"You need close to a billion transistors to create a competitive processor today," says the distinguished engineer.

One reason is that each new processor has to be fully compatible with previous versions, so you can't take anything out.

"SPARC has been around for 20 years and has accumulated an awful lot of baggage over that time – things that were once a good idea but now aren't considered to be that valuable, and yet we have to implement all of them in hardware for backward compatibility," Wolczko says.

That's one of the central tenets of SPARC and most other processors, but Project Portmeirion shows there may be a way around that.

In a word, software.

"We said, 'What if we provided a translation system, or an emulation system, that would take the pieces of the hardware that aren't paying their own way and implemented those in software instead?' It won't really matter if they're a little bit slower in software because they're not important anyway."

The concept caught on instantly.

"It was kind of strange in that Greg and I talked this through and figured out, 'Yeah, we might have something here.' So we wrote up a simple proposal as to what this project would be, and there was all sorts of interest," Wolczko says. "We kind of sold the project long before we did anything, which is quite unusual for a labs project."

Their next step was to check with folks in the Microelectronics group.

"They gave us quite a long list, but two or three things really stood out as considerable implementation burdens but perhaps not such a great value to end users these days," he says.

"The top two or three are really significant design efforts – things that either take many, many person years to design and verify, or that take a large area of the chip."

The others on the list represent small improvements – a few percent here and there – but there are dozens of them.

Wolczko is quick to note that this approach is not entirely new -- and was not entirely successful when others tried it in the past.

However, things have changed.

"We have a great deal of experience writing virtual machines and advanced translators in the context of Java . The Java HotSpot virtual machine and its predecessors embody a degree of sophistication which hasn't been in commercial binary translators before," he says.

"We think the software can be pushed to a new level no one has got to before. We think we can do that based on the experience we've got with Java."

Wolczko also notes that earlier attempts, notably by Transmeta Corporation, targeted desktop or notebook computers.

"When Transmeta tried this nearly 10 years ago it was a single-core processor, and when the translator kicked in, the user program stopped running and that pause was visible to the user," he says. "So if you were sitting at your laptop playing Doom or some other popular game of the time and that translation spent more than a few milliseconds doing its work, you'd see a glitch in the display. Customers would not tolerate that."

On a server, life is different.

"You can pretty much guarantee there are plenty of processor cores around, so you can dedicate some amount of that to doing the work of the translation," he explains.

A key element of Project Portmeirion – the ability to optimize code on the fly – goes all the way back to the first project Wolczko worked on when he joined Sun 15 years ago, the Self programming system.

"The core idea of the implementation was that you started running the program with a relatively dumb translator and you observed what the program was doing. As you observed you made optimization decisions based on what you saw. So code that wasn't running, you didn't bother optimizing because, well, it's not running. Why bother?" he says.

That stands in stark contrast to traditional software compilers that examine all the code, pick an optimization strategy, and eventually deliver the final binary.

The nature of the Self language made that all but impossible, so researchers had to find a way around it – and they did.

"Once the program was running you could narrow the huge space of possibilities down to the one or two that were actually happening and optimize for those. Again, who cares about the rest? If they're not happening, no problem," Wolczko explains.

"What you'd have to do is put in the checks to make sure that if your assumptions were wrong, you would back out and do the thing right the second time. But we sort of mastered that the first time around in Self, and then all that technology flowed into HotSpot and Sun has been shipping that technology and refining it now at product level for 10 years, so we feel a mastery of that which very few other companies actually have."

Wolczko says that he and his team (which includes Wright, Peter Hsu, Peter Kessler, Kevin Moore, and Chris Vick) are about six months from completing the first software prototype needed to test and refine Project Portmeirion and ultimately prove that it really is a better approach.

"The idea is to give the hardware people, the people who do the real product, some breathing room. They can choose what they want to do with that breathing room. Do they want to bring the chip to market faster? Do they want to make the chip smaller? Do they want to burn less power?" he asks.

"It's up to them what they want to optimize for because the problem is strictly simpler than it used to be. They can put the breathing room we buy them into whatever they want. This is neutral with respect to all those choices. It doesn't preclude any direction. It's a systematic way you can look at the existing architecture and take out the stuff that doesn't pay its own way. That goes into software and what you save you can now use in any way you like."