Be honest. You don’t think of Lubbock, Texas, as anywhere close to the center of the technology universe.  So it may come as a surprise that a technology that was born there, at Texas Tech University, may radically change the computer industry. Texas Tech lacks the cachet of Stanford or MIT or Berkeley, but it could end up having as big an impact on computing as those other educational IT powerhouses. If so, then kudos to Professor Daniel Cooke, who is the man behind SequenceL.

So what is SequenceL?

It is yet-another-programming language. And as there are now more programming languages than human languages, you can be forgiven for reacting with; “Yawn, sigh, who needs another one?” But truth to tell, it is not a new language. It’s been around since 1996 and it’s an interesting language in two ways at least.

First of all, it exists because of research funded by NASA, which wanted a language for specifying program design effectively. The language needed to be executable and it needed to be “Turing complete.” If you don’t know what that means, it means capable of specifying any process a computer can execute. NASA also wanted a language that was easy to read – no surprise given that the purpose of the language was to write specifications. SequenceL was the language that Professor Daniel Cooke designed and NASA was happy with it.

The irony is that there was no pressing need to write a compiler for it, because the goal was for a language that people rather than computers would read. And that’s ironic because compiled SequenceL may be the solution to the multicore problem.

So what is the Multicore Problem?

The multicore problem is this:

In 2004, the chip industry hit a brick wall. It was no longer possible to increase the speed of chips by increasing the clock speed. Clock speeds had risen to about 4 gigahertz and even at that speed, they were giving out far too much heat to be practical. If the clock speed were raised any further, the heat output would be unmanageable. (Anyone who’s ever suffered from a hot laptop on the lap knows all about this.)

Consequently, to deliver more power to each new generation of chips, chip vendors (Intel, AMD, IBM et al) began adding more processor cores to the chip. Ostensibly that was fine. A two-core chip executes twice as many machine instructions as a single-core chip, and four cores are twice as powerful as two. Practically, you could divide up computer workloads reasonably efficiently between 2 cores and, although it is far less effective, even between 4 cores. But beyond that, and even with such small numbers of cores, you need software that can run in a parallel manner to exploit the available power. So the problem comes down to this:

• Very few of the applications we run operate in parallel
• Very few programmers have any idea how to write parallel code

Why is that a problem, really?

The chip business is based on obsolescence. Vendors make new generations of chips that are better than the previous generation, and the previous generation of chips quickly becomes obsolescent. New applications appear that exploit the extra power and businesses and consumers eventually want to upgrade to take advantage.

The chip vendors’ business model is predicated on delivering more power every 18 months or so, and for decades they’ve been doing that at a brisk pace. If the multicore strategy fails, their business model breaks.

What does SequenceL have to do with any of this?

“Nothing at all,” would have been the answer had Prof. Daniel Cooke not had a Ph D student who was looking for a Ph D project. They jointly agreed that a suitable project would be to write a compiler for SequenceL and as both of them were interested in parallel processing, the Ph D student chose to write a compiler that made good use of parallelism.

As the work proceeded, it became clear that SequenceL could be automatically parallelized very efficiently. To cut a long story short, the outcome was (eventually) the founding of a software startup called Texas Multicore Technologies (TMT) to exploit the parallelism that SequenceL can deliver.

So how does it work?

SequenceL is a declarative language. A declarative language is one that tells the computer what to do, but not how to do it. There are not many declarative languages; the only two that have seen much use at all are SQL (for accessing databases) and the AI language Prolog.

The more familiar kind of programming language is the procedural language, which tells the computer both what to do and how to do it. Nearly all the commonly used programming languages are procedural; C, C++, Visual Basic, COBOL, Java, Python and so on. In those languages the programmer can easily order the computer to do something in an inefficient way, and given that programmers haven’t cared much about computer performance for many years, that’s often what happens.

In a declarative language, there is no specification of how to carry out a task and consequently, it is possible to have the compiler choose efficient ways to do things. So, given a declarative language and a multicore environment, the compiler can make all the choices about how best to exploit multiple cores.

The way that SequenceL is converted into an executable program is illustrated in the diagram. The compilation process consists of two passes. First, a compiler converts SequenceL into parallel C++ source code. (It’s a hybrid compilation/interpretation process.) It carries out “large grain parallelization” producing parallel C++ code. The second pass is through a C++ compiler that has a special set of parallel libraries. You can think of that as a “fine grain parallelization,” which augments the parallelization of the first pass.

How well does it work?

All the evidence available so far is that SequenceL parallelizes with surprising efficiency. There’s anecdotal evidence, based on specific instances of where the technology has been applied and there’s some benchmark evidence.

First the anecdotal. One of the initial customers of TMT had a specific program within a process control system that needed to run far faster than it currently did. It normally took about 3 hours to run and, of course, it never tried to exploit parallelism at all. So TMT rewrote the program in SequenceL and compiled it, and it ran in 2 minutes on a 16 way configuration – 90 times faster.

Initially TMT found this very confusing, because the absolute best that they had thought possible was to bring the run time down to 12 minutes (about 15 times faster.) So they analyzed the source code of the original program and concluded that the programmer had written it in a naïve manner with little focus on performance. This anecdote surfaces an interesting aspect of this technology. It doesn’t provide the programmer with as many opportunities to write code badly as a procedural language does.

Although they are few, there are some programmers who are skilled in writing parallelized code. With another customer, TMT was challenged to rewrite a program that had already been parallelized by such skilled coders. SequenceL managed to outperform those programmers by a factor of 50 percent.

Finally, in a formal benchmark with a chip vendor, SequenceL achieved 100 percent efficiency of parallelization on a 16 way CPU.

None of these specific examples provide any rule of thumb. However, this technology is new and exactly what level of efficiency it can be expected to deliver is not yet clearly apparent. Nevertheless, a range of effectiveness is beginning to emerge. Currently TMT believes that the low water mark for SequenceL is 50% efficiency of multiple core usage, and the high water mark, as the benchmark suggest, is 100%.

If SequenceL consistently performs in that range, then it surely delivers the solution to the multicore problem.