Original URL: https://www.theregister.com/2008/06/06/gates_knuth_parallel/

Multi-threaded development joins Gates as yesterday's man

Knuth and Bray call time

By Phil Manchester

Posted in Channel, 6th June 2008 05:02 GMT

When he wasn’t ruminating at this week’s TechEd on the “millions” of servers running Microsoft’s planned on-demand services, Bill Gates was talking about how to architect software to take advantage of powerful “transistors” in massive server farms.

Applications - like, for example, Microsoft’s BizTalk Server and SQL Server that the company is talking about making available as on-demand services - will need to be broken down into “parallel execution units”, Gates said.

“We have an incredible amount of work at Microsoft to make the runtimes higher level, and to make it easy to take your code and write it in this parallel fashion. There will be a lot of discussion about this so-called 'multi-core' revolution in how we make sure we're all doing the best to take advantage of that,” Gates said. It was his last bout of TechEd crystal-ball gazing before stepping down from day-to-day responsibilities as Microsoft chairman next month.

The rub

Devising new approaches to building software and educating programmers to cope with parallel processing is causing concern, though, and has prompted software heavyweights to join the debate. Before Gates took the stage in Orlando, Florida, programming pioneer Don Knuth and XML architect Tim Bray raised doubts about multi-threading - one of the main programming techniques for multi-core systems.

While multiple processor systems have been around for decades they have usually been associated with specialist systems - such as Cray's supercomputers. During the 1980s the UK company Inmos set out to build a commercial parallel processing chip with its transputer but it failed.

Continuing commercial pressure and improving processor power have revived multiple processor architectures, bringing them into the mainstream. Chip makers have argued that, as chip fabrication techniques reach physical limits and Moore's Law becomes obsolete, one way to get more power from hardware is from innovations in architecture. The simplest way to achieve more power is to increase the number of processors with multi-core chips, clusters of processors or networked grids.

But multiple processor architectures introduce a new class of programming problem. Writing software to get the best performance from multiple-processor systems is far from straightforward. Issues such as synchronization, load balancing, memory protection and task distribution place new demands on programmers and those building tools that are used by developers.

Bill Gates in Microsoft last day video

Gates grapples with parallel computing

There is clear evidence that the industry is aware of the problem. Although Intel estimates that only one in a hundred programmers has any experience of programming multiple processor systems, an informal poll of around 1,200 programmers last year showed that most were aware of the need to approach programming in a different way.

Chip builders have concentrated on the use of multi threading. Intel, for example, has invested heavily in multi-threading technology with its thread building blocks (TBB) library extensions to C++.

But the validity of multi threading is under attack. Veteran programmer Knuth said in a recent interview that multi threading may not be up to the task and could fail. As such, he is "unhappy" with the current trend towards multi-core architectures.

“To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multi threading idea turns out to be a flop, worse than the ‘Titanium’ approach that was supposed to be so terrific - until it turned out that the wished-for compilers were basically impossible to write," Knuth said.

Knuth - the author of the seminal programmers' manual The Art of Computer Programming and a Turing Award winner - has to be taken seriously on this. And he is not alone. Sun Microsystems' director of web technologies Tim Bray, one of the team that created XML, has also criticized multi threading. Bray said that, while he once favored the approach, he had now turned away from it. Elsewhere the criticism of multi threading is even more direct.

There appear to be two schools of thought emerging on how future software developers should cope with the challenge of programming multiple processor systems.

One school says the complexities should be hidden by the tools leaving programmers to concentrate on their applications. Compilers and operating systems should take care of issues such as synchronization and load balancing. This is in essence the aim of multi-threading strategies such as Intel's TBB and similar approaches by AMD.

The other school argues that programmers should be educated in functional languages such as Lisp and Erlang. Jack Dennis, professor of computer science and engineering at MIT, believes a combination of education in functional languages and exposure to the problems of synchronization could help. He also argues that functional languages effectively avoid some of the problems of programming multiple processor systems.

Devil in the details

Like the two lead characters in Robert Pirsig's Zen and the Art of Motor Cycle Maintenance one school sees the underlying complexity of the machine as something to be avoided at all costs and the other relishes the intricacies of its internal workings.

Clearly there's a lot more work left to do. Both from a practical and a philosophical perspective, as the industry must agree not just to take action on programming for parallel systems, but also decide what is the best approach to take. And achieving lasting consensus could be the hardest part of the puzzle. As we are discovering on multi threading, what was once considered "right" can fall out of favor and be branded as "wrong".®