About

Did you know there’s a programming language that’s already proven itself in a huge number of sensitive applications and which inherently supports task-based programming? It’s not something that’s just come out of the labs in Silicon Valley. It’s been around for decades, and it’s called Ada. No! Don’t run away. I’ve got some interesting research to share that might persuade you it’s worth a second look.

He compared the serial and task-based performance of two applications: one for word counting and another for calculating checksums. The serial application ran the same code but implemented it using a loop instead of tasks. He recorded the programs’ performance using various numbers of cores (from 1 to 32), which gives some insight into scalability and any overhead inherent in the tasking model.

On the word count algorithm, the elapsed time decreased as the number of tasks increased. The performance increase wasn’t quite linear, because of the effect of file I/O. The checksum program used fewer I/O operations, and so saw a decrease in elapsed time that increased more linearly as more tasks were used. The tasking overhead limited total throughput to about 50%, though, Nyberg said.

The research was published a couple of years ago, so it’s interesting to think about what’s changed since 2007, and what hasn’t. The research paper comes from a time when multicore chips still commanded a price premium which customers might be reluctant to pay. Now, they come as standard on the desktop PC, although machines with more than four cores are still relatively rare, and customers might be reluctant to pay for additional cores. For high performance computing, massively multicore hardware still requires a significant investment, although it’s much easier to get low-cost systems for modelling multicore hardware.

In his 2007 presentation, Nyberg speculated that it will take years for industry to leverage multicore hardware, which turned out to be spot on. We’re still working on that problem, and while the tools and techniques are getting better, multicore programming isn’t rapidly becoming more accessible to the vast majority of programmers. Nyberg noted that Ada was ready in 2007, and it’s still ready now. So why aren’t people using it?

Nyberg believes the reasons are largely cultural: Ada is still tainted by its defence background and lacks cool, he says. It also works in a smaller universe. It might be used on hundreds of planes, but Java is on 5 billion devices, he notes.

The lack of cool is something that probably bothers programmers more than they’d be willing to admit. Which isn’t to say they use languages because they’re fashionable, but more that they like to be part of a community with plenty of buzz and innovation, and Ada doesn’t offer that as well as other platforms do. While Ada has tasks built in to the core language, it will require many programmers to learn a new language from scratch. Many will find it easier to work with bolt-on parallel programming solutions that extend a language or toolset they already know.

I wonder whether programmers are missing an opportunity, here, though? What do you think?

Thanks for the kind words. More specific research on other applications for the T1000 in multicore Ada programming here: http://karl.nyberg.net/t1000.

Frankly, for me, it’s not so much the cool factor as it is the job factor. I really like Ada (but then, I like asparagus, too :-)) and have both evidence and belief that it is a much more cost-effective language in which to develop software, but there’s all those things associated with living that require money that as a consultant / contractor (versus a product developer / entrepreneur) I use other languages for my daily work and Ada for mostly avocational pursuits.

Hi Karl. Thanks for your comment and the link to further information. It’s interesting that you’re seeing a difference between the technologies that you use for consultancy work and those you use for your own research. Most technologies that take root in businesses start off as the pet projects of influential developers close to the business, so this could be a way in for Ada. On the other hand, legacy code creates an awful lot of inertia which could prove difficult to overcome.

Programmer productivity is always a concern, so tools that make it easier to write good code are always welcome. I think there’s a difference between the level of productivity that comes from a fluent understanding of the language and insight into great programming solutions, and the boost that good tools can give in creating the code, though. Not sure how easy Ada is to understand compared to other parallel languages/frameworks, but having inherent support for tasks must make it more intuitive for some programmers to write parallel code in, which must also speed up development a bit (for some, at least).

“Programmer productivity is always a concern, so tools that make it easier to write good code are always welcome. I think there’s a difference between the level of productivity that comes from a fluent understanding of the language and insight into great programming solutions, and the boost that good tools can give in creating the code, though.”

“Vision Systems Ltd. of Australia cut their bug rates from 1 every 80 lines using C to 1 every 270 lines using Ada, and cut their testing time from 9 months to less than 4 months.

“The seminal comparison of Ada and C projects is Rational Software’s 1995 study (also available as a pdf file). Verdix (which merged into Rational in 1994) had about 50% of their 3 million lines of code in C and 50% in Ada. The code was maintained by the same developers over the course of 11 years, yet the Ada code had about half as many defects and the overall development cost was about 35% less for Ada code.

“This effect extends to academia as well. John McCormick reports that students in his course on real-time embedded software development fared much better using Ada rather than C. In fact, no one finished the project when using C, even given 60% of the code. On the other hand, 75% of the class finished the project when using Ada, even given a much smaller portion of the code (less than 20%). ”

McCormick’s findings comment on the influence of how well the user knows the language: His students knew C well, but did not know Ada. They still did significantly better using Ada than C.

Thanks for your comment and that link. There are some fantastic data points there. I think programmers choose their preferred programming languages sometimes for fuzzy reasons they can’t define, so data like that can help managers to make a good business case for Ada. Particularly since non-programmming managers must often depend on programmers to recommend the technologies the business uses.

The statistics Jeffrey quoted were based on 7 years of teaching C and 13 years of teaching Ada. The students in my Real-Time Systems class work in teams of three or four to write 10-12K lines of Ada to control a large model railroad. See

The project involves over 30 tasks (threads). This course is the students first experience with concurrent programming. Most graduates of this course go on to careers in developing software for avionics. The success of this course has inspired a new textbook for novices – Building Parallel, Embedded, and Real-Time Applications with Ada which will be available January 2011. Seehttp://www.cambridge.org/us/catalogue/catalogue.asp?isbn=9780521197168

I have a more recent data point on effect of first language on learning programming principles. For the past three years my university had two sets of first year courses – Introduction to Programming and Data Structures. Half our Freshman used Ada and the other half used C++ for these two courses. All students then take a Java based OO design/programming course. The difference in performance in the OO course between those students with the Ada background and those with the C++ background was amazing. No more than two C++ students each semester did better than the bottom Ada student. My department’s reaction to this overwhelming difference? Replace the C++ with the sexier Python language. So I guess we’ll see how those two languages compare over the next few years.

Hi John. Thanks for your comment. That’s an interesting data point, which suggests Ada prepares students better for Java and OO work than C++ does. Are there significant parallel elements in the Java course which Ada smoothes the way for, or do you think there are other factors involved?

The Java course does not deal with any parallel issues so this discussion may be getting a little off topic. I attribute the success of the Ada students to having to spend less time on syntax and debugging than their C++ counterparts. Ada compilers produce amazingly good messages for novice programmers. The Ada students spend of lot of time modeling scalar values which may prepare them better for modeling classes. For the C++ student, any whole number is an int while the Ada student wants to know the range that number might take.

The final verson of the manuscript goes to the publisher next week. Then it is up to the artists and editors to do their magic.