Organisers of the Multicore World conference in Wellington last month are touting the rising importance of multicore management and parallel processing as a potential niche market for New Zealand.
The event attracted luminaries from microprocessor leaders Intel and ARM as well as representatives of software companies, “big data” users such as the Square Kilometre Array project and Weta Digital and of venture capitalists and NZ Trade and Enterprise.
It was rare to have the two microprocessor giants sitting in panel sessions together, says organiser Nicólas Erdödy, director of Open Parallel. This, he suggests, is testimony to the importance of a forum on the productive use of multicore microprocessor chips.
The juxtaposition brought some frank disclosure over the conference dinner, when Tim Mattson of Intel and ARM’s John Goodacre were neighbours at the same table as Computerworld “You [ARM] are kicking our ass,” Mattson acknowledged to Goodacre, praising the competitive environment as a stimulator of innovation.
Mattson went on to discuss future options for the development of Intel chips in that competitive environment, but was careful to label his comments off-the-record at that point.
A significant thread of the discussion on the first day was the inadequacy of programming languages to deal natively with the management of parallel processes running on the same chip. James Reinders of Intel discussed the lack of native parallel processing instructions in C, C++ and Fortran and the potential and some limitations of the Open MP API and Cilk Plus parallel processing extensions to C and C++.
Some older techniques of parallel processing involve complex management of locks, said Reinders and this can militate against the scalability of an application. A poorly-written algorithm might even produce different results under different conditions of lock management. He advanced transaction-oriented programming as a method that would “make things simple again”.
“If your algorithm produces different results [under different locking sequences], then it’s your algorithm that’s broken, not the parallelism,” said Mattson, later.
Abstraction was another key topic; a number of delegates expressed doubt that many application developers would delve into the complexity of managing multiple threads; perhaps this work would be done by a minority and there would be some way of presenting a relatively straightforward interface to enable the rest of the of developers to use the increased processing power conferred at a deeper level by parallelism. Most developers would “continue to think sequentially,” said Martin McKendry, member of the US-based advisory board to Open Parallel.
The comparison was made between using a more powerful engine simply to make a truck go faster and using it to power more innovative uses.
At and between sessions, delegates canvassed ideas for practical use of parallel processing capacity; ideas included a voice-recognition system whose accuracy would be enhanced by concurrent lip-reading, and a scheme for universal and transparent encryption of documents to avoid their being disclosed to the wrong people, as recently in evidence at ACC.
The rules of using parallelism intelligently, correctly and productively will eventually permeate the developer community, said Reinders.
McKendry cautioned that too easy an implementation of parallelism could encourage “feature bloat,” with developers putting in marginally relevant functionality simply to use the extra processing capacity they were given.
Conversation was intense in the breaks between sessions and it was often difficult to get delegates back from their individual interactions to listen to the next formal presentation.
Erdödy had his own way of judging the success of the conference; halfway through the morning break on the first day, he pointed to the piles of muffins and pastries still on the tables. People are more interested in talking with one another than eating, he said. In a more typical conference, “all this food would be gone by now”.