Steve Lionel on Why Fortran Still Matters

Steve Lionel says Fortran, at 54 years old, remains important in an era when most programmers focus on languages like PERL, Python and Java. Lionel, also known as Dr. Fortran, is a senior member of Intel’s technical staff, and has a long history with Fortran having developed Fortran compilers at Digital Equipment Corp.

Q: Is Fortran still relevant? You don’t hear many developers talking about this venerable programming language.
Steve Lionel:
It is absolutely still relevant. Fortran itself is venerable, but that doesn’t mean it hasn’t changed. The Fortran standard has received five updates. The last was in October, and each time new capabilities are added, some of which are vendor extensions that programmers wanted, some of which are features that became popular in other languages and got adopted.

Q: What are some features Fortran borrowed from other languages?
C++ had classes and polymorphic features that were added to Fortran in 2003.

Q: What are its other strengths?
Fortran 2008 has built-in parallel programming capabilities that no other widely used language has. Other languages have parallel programming features, but Fortran incorporated modern parallel programming in ways that none of the other languages have. There is an incredible body of well-written and well-debugged routines in Fortran that are out there for reuse.

Q: Are new applications being written in Fortran?
There are lots. If you look at hurricane forecasting applications, most of the modern models are written in Fortran. The Weather Research and Forecasting Model (WRF) is largely written in Fortran.

There is an automobile crash simulator called PAM-CRASH written in Fortran. Lots of engineering code, optical modeling, nuclear physics work is done in Fortran. Fortran remains the pre-eminent language in high-performance computing (HPC).

Q: So why aren’t more people using it?
I don’t want to leave the impression that everything is written in Fortran. It’s a relatively smaller part of the market than 20 years ago, but it isn’t dying. Yes, there’s a lot of C and C++ that is more appropriate for certain things than Fortran is.

Q: What applications are best written in Fortran?
For something like string processing, Fortran would not be my first choice. But if you’re doing number crunching, working with a lot of floating-point data, or doing parallel processing, it’s an excellent choice. Its strengths in array operations -- its wide variety of routines -- make it attractive, and there is a huge library of freely available high-performance routines written over 40 years that still work together.

With a lot of other languages, when they update the standard, they introduce incompatibilities. The Fortran standards group is very careful not to do that.

Open-source Databases in the Post-Oracle World

Open-source products, like MySQL and PostgreSQL, brought relational database functionality to the masses at a fraction of the price of a commercial Oracle, IBM or even Microsoft database. MySQL led the pack of free, or almost free, contenders -- customers typically paid for support, not the database itself. Sun Microsystems bought MySQL in January 2008 and open-source fans saw Sun, which fostered many open-source projects, as a worthy caretaker. But, when Oracle bought Sun two years later, they were no longer pleased. Oracle was not known for its friendliness to open source. Here, MySQL veteran Ulf Sandberg -- now CEO of SkySQL Ab -- says prospects remain rosy for open-source databases as the world transitions to cloud computing.

Q: When Oracle bought Sun Microsystems (which had already acquired MySQL), many feared the worst for the open-source database. How has that worked out?

Ulf Sandberg:
When the Oracle news was announced, we all thought “uh oh.” Oracle was not exactly known for open source. It’s very bottom-line focused, focused on shareholder value. But on open source? No.
That triggered us to think of an alternative to Oracle. MySQL co-creator Monty Widenius started his project, MariaDB, and he’s making MySQL better, adding features so that MySQL continues to live with its creator. It’s not a fork; he builds against the current version of MySQL.

Q: Has Oracle kept up with this on its own?

We thought Oracle would not pay a lot of attention to MySQL, and that there should be an alternative. That doesn’t mean that Oracle is doing anything wrong. They changed some things; they changed pricing in November, they changed license agreements, so you now have to click through and sign up … and that upset people. They wonder “Why should we pay them?” But there is still a free version of MySQL.

Q: What about PostgreSQL and other open-source databases?

Postgres [sic] and MySQL are pretty close feature-wise. If you evaluated them as a technical person, it’s a tossup. You might find one feature in one that’s better than the other, but there’s not a huge difference. The big thing was that MySQL had a company behind it and a complete service organization, and that made it take off. The installed base of MySQL is 10 times that of Postgres.

Q: What applications are good for open-source databases, and which are better run on commercial databases?

Open-source databases are tailored for the new world of the Web and online. Traditional databases are monolithic; they were designed decades ago and they run legacy applications.

MySQL is still growing very fast and the sweet spot is still the Web. Companies that grew up building online apps don’t want to spend a ton of money on a big database. Facebook and Google, these are the types of customers that grew up on open-source databases.

There is nothing wrong with spending a lot of money on a commercial database. These are great products, but do you really use all that capability?

The next thing for open-source databases is the cloud. One thing that suits MySQL for cloud is that it supports pluggable storage engines that let you change the behavior of the database for different markets. The elasticity of the cloud opens up a whole new space for us and that’s where IBM, Oracle and Microsoft are stuck. They don’t have the key things needed for the virtualized world of cloud. If you turn on faucet, it should follow your needs; you shouldn’t have to install a whole new database if your need gets bigger.

Maxing out Multicore

From smartphones to data centers, multicore processors are becoming the norm. The extra processing power is good news for developers, but there’s a catch: The real-world performance gains are often held back by old ways of thinking about coding, a caveat summed up in the oft-overlooked Amdahl’s Law.

More than two years ago, University of Wisconsin Professor Mark Hill gave a presentation about how Amdahl’s Law affects multicore performance. He recently spoke with Intelligence in Software about why parallelism is key to unlocking multicore’s benefits and why the computing world could use a new Moore’s Law.

Q: In your presentation, you mentioned a conversation you had in a bar with IBM researcher Thomas Puzak. He said that everybody knows Amdahl’s

Law but quickly forgets it. Why?

Mark Hill: You learn the math of this, but often when it comes to real life, you forget how harsh Amdahl’s Law really is. If you’re 99 percent parallel and 1 percent serial, and you have 256 cores, how much faster do you think you can go? You’d think you get a speed-up of maybe 250 out of 256. (A speed-up for 250 means that one is computing at 250 times the rate of one core.)

But the answer is a speed-up of 72. That 1 percent has already cost you that much. That’s the kind of thing I mean. People’s intuition often is more optimistic than if they did a calculation with Amdahl’s Law.

Q: Hence your point about why there’s a growing need for dramatic increases in parallelism.

M.H.: Correct. It also ties in with the fact that I don’t think you’re going to take old software and get dramatic parallelism because it’s going to get that sequential component down.

Let’s say you get the sequential component down to 35 percent. Then your

speed-up is limited to three -- at most three times faster than a single core. Nice, but hardly what you want. So in my opinion, dramatic gains in parallelism are going to have to happen due to new software that’s written for this person.

Q: For developers, what are the challenges to writing parallel-centric software, for lack of a better term? Is it mainly a change in mindset?

M.H.: It’s a pretty huge hurdle. There have been people writing parallel software in niche domains such as supercomputers, but most developers don’t have experience with it. If you think of software as a numerical recipe -- you do this, you do that -- parallel computing is like a bunch of numerical recipes operating at the same time. That can be conceptually a lot more difficult. It can be easier if you have a large dataset and say, “Let’s do approximately the same thing on each element of this large dataset.” That’s not so mind-blowing.

Part of the problem is that the literature can be a little biased because you can more easily publish results that show things working fantastically than working poorly. If you read these papers, you might think things are working pretty well, but people select things they want to publish with as opposed to the problems need to be done.

Q: You’ve talked about the need for a new Moore’s Law, where parallelism doubles every two years.

M.H.: It used to be that you could design a piece of software, and if it ran like a pig, you could say, “Well, it’s not a problem because processors are going to get twice as fast in two years.” Going forward, that’s going to be true only if you get parallelism that keeps increasing. That’s not going to happen by luck. You’re going to have to plan for it.

Q: Maybe there’s an analogy with oil: When gas prices skyrocket, as they did in the 1970s and again today, automakers start looking for ways to wring every mile they can out of a gallon. In the computing world, enterprises want data centers that aren’t electricity hogs, and smartphones that can last an entire workday before they need a charge.

M.H.: Electricity is increasingly becoming the limiting factor in machines. In this new era, there’s going to be a lot more pressure for the code to be more efficient. People say, “That doesn’t matter anymore because computers are so fast.” Yeah, but if my code is twice as efficient as your code, that’s going to matter because if somebody’s battery lasts twice as long, it’s a very good thing.

To download the slides from Hill’s presentation, visit .

Photo Credit:

Why Is Parallel Programming So Hard

Most people first learn how to program serially. Later they learn about multitasking and threading. But with the advent of multicore processors, most programmers are still pretty intimidated by the prospect of true parallel programming.

To help serial programmers make the transition to parallel, we talked to distinguished IBM engineer Paul E. McKenney. (McKenney maintains RCU in the Linux kernel and has written the detailed guidebook Is Parallel Programming Hard, And, If So, What Can You Do About It? ) Here’s what he had to say.

Q: What makes parallel programming harder than serial programming? How much of this is simply a new mindset one has to adopt?

McKenney: Strange though it may seem, although parallel programming is indeed harder than sequential programming, it is not that much harder. Perhaps the people complaining about parallel programming have forgotten about parallelism in everyday life: Drivers deal naturally with many other cars; sports team members deal with other players, referees and sometimes spectators; and schoolteachers deal with large numbers of (sometimes unruly) children. It is not parallel programming that is hard, but rather programming itself.

Nevertheless, parallelism can pose difficult problems for longtime sequential programmers, just as Git can be for longtime users of revision control systems. These problems include design and coding habits that are inappropriate for parallel programming, but also sequential APIs that are problematic for parallel programs.

This turns out to be a problem both in theory and practice. For example, consider a collection API whose addition and deletion primitives return the exact number of items in the collection. This has simple and efficient sequential implementations but is problematic in parallel. In contrast, addition and deletion primitives that do not return the exact number of items in the set have simple and efficient parallel implementations.

As a result, much of the difficulty in moving from sequential to parallel programming is in fact adopting a new mindset. After all, if parallel programming really is mind-crushingly difficult, why are there so many successful parallel open-source projects?

Q: What does a serial programmer have to rethink when approaching parallel programming? Enterprise programmers know how to multitask and thread, but most don’t have a clue how to tap into the power of multicore/parallel programming.

McKenney: The two biggest learning opportunities are a) partitioning problems[SK7]  to allow efficient parallel solutions, and b) using the right tool for the job. Sometimes people dismiss partitioned problems as “embarrassingly parallel,” but these problems are exactly the ones for which parallelism is the most effective. Parallelism is first and foremost a performance optimization, and therefore has its area of applicability. For a given problem, parallelism might well be the right tool for the job, but other performance optimizations might be better. Use the right tool for the job!

Q: What can best help serial programmers retool themselves into parallel programmers?   

McKenney: All tools and languages, parallel or not, are domain-specific. So look at the tools and languages used by parallel programmers in application domains that interest you the most. There are a lot of parallel open-source projects out there, and so there is no shortage of existing practice to learn from. If you are not interested in a specific application domain, focus on tools used by a vibrant parallel open-source project. For example, the project I participate in has been called out as having made great progress in parallelism by some prominent academic researchers.

But design is more important than specific tools or languages. If your design fully partitions the problem, then parallelization will be easy in pretty much any tool or language. In contrast, no tool or language will help a flawed design. Finally, if your problem is inherently unpartitionable, perhaps you should be looking at other performance optimization.

Back in the 1970s and 1980s, the Great Programming Crisis was at least as severe as the current Great Multicore Programming Crisis. The primary solutions were not high-minded tools or languages, but rather the lowly spreadsheet, word processor, presentation manager, and relational database. These four lowly tools transformed the computer from an esoteric curiosity into something that almost no one can live without. But the high-minded tools and languages of the time are long forgotten, and rightly so. The same thing will happen with parallelism: The average person doesn’t care about fancy parallel languages and synchronization techniques; they just want their smartphone’s battery to last longer.

Of course, I have my favorite languages, tools and techniques, mostly from the perspective of someone hacking kernels or the lower levels of parallel system utilities. I have had great fun with parallel programming over the past two decades, and I hope your readers have at least as much fun in the decades to come!

For more on this topic, check out Paul E. McKenney’s blog.


Is Ubicomp at a Tipping Point?

The Palo Alto Research Center (PARC) coined the term “ubiquitous computing” in 1988, but it took the next two decades for the PARC researchers’ vision to start becoming a part of the workplace and the rest of everyday life. As manager of PARC’s Ubiquitous Computing Area, Bo Begole  is shepherding ubicomp into the mainstream with some help from a variety of other trends -- particularly the growth in cellular and Wi-Fi coverage, smartphone adoption and cloud computing .

Begole recently discussed what enterprises need to consider when deciding where and how to implement ubicomp, both internally and as a way to better serve their customers. One recommendation: People need to feel that they’re always in control.

Q: The term “ubiquitous computing” means a lot of different things, depending on whom you’re talking to. How do you define it? Where did the term originate?

Begole: It kind of came on the heels of personal computing, which had superseded mainframe computing. So there was that pattern of naming. But what was distinct about ubiquitous computing in contrast to those others is that “mainframe computing” and “personal computing” always implied that a computer was the center of your focus.

I wanted to be able to conduct computing tasks ubiquitously: wherever you were, and whenever you needed it, as you were conducting your daily life. It’s more about ubiquitous working or living and using computer technologies in the course of that.

Q: Ubicomp dovetails nicely with another trend: cloud computing, where you’ve always got access to a network of computers.

Begole: Right. The cloud is an enabler of ubiquitous computing because you need constant access to the information services that you might utilize at that point. The PARC researchers, having lived with the personal computer for 15 years at that point, were envisioning this paradigm, and they saw that it was going to involve ubiquitous devices and also ubiquitous wireless networks. So they started to prototype those types of devices and services.

Q: Ubicomp seems a bit like unified communications: For at least the past 15 years, visionaries and vendors were touting unified communications as the next big thing. But it wasn’t until a few years ago that enterprises had deployed enough of the necessary building blocks, such as VoIP and desktop videoconferencing. Now unified communications is common in the workplace. Is ubicomp at a similar tipping point?

Begole: That’s a good analogy because unified communications requires critical mass of adoption of certain services, and then the next stage was to make them all interoperable. That’s what’s happened with ubiquitous communications too. The early researchers saw the inevitability of these pervasive devices and networks, and they prototyped some. But it’s taken a while before there existed the critical mass of smart devices and wireless networks.

I’d say that the tipping point was around 2005 to 2007, when smartphones came out. GPS chips embedded in those phones really enabled those kinds of context-aware services that ubiquitous computing research had been pushing for a while. The next wave is very intelligent context-aware services. The Holy Grail is a personal assistant that has so much intimate knowledge of what matters to you that it can sometimes proactively access information for you and enable services that you’re going to need in the very near future. That’s where things are going.

Q: Here’s a hypothetical scenario: My flight lands. I turn on my smartphone, which checks my itinerary and uses that to give me directions to baggage claim, the rental car desk and my hotel. But it also tells me that on the way to baggage claim, there’s a Starbucks, which it knows I like because of all the times I’ve logged in from Foursquare. Is that an example of the types of day-to-day experiences that people can expect from ubicomp?

Begole: Even a little beyond that. Maybe you like an independent coffee brewer in your local area. Now you’re in a new local area, so rather than recommending Starbucks, it will find the most popular local brewer because it knows the types of things you’re interested in.

It’s connecting the dots, which is what we expect humans to be able to do, and it’s possible for computers to be able to do it. They have access to all this kind of information. The smartphone is a good hub for that because it’s got access to all of your digital services, and it has intimate knowledge about your physical situation at any time.

Q: That scenario also highlights one of the challenges for ubiquitous computing: balancing the desire for personalization with concerns about privacy.

Begole: Ubiquitous computing services have to be respectful of the concerns that people have. Otherwise, it’s going to limit the adoption. It’s a little different for consumers than for enterprises. Employees probably have a little less expectation about the privacy of the data they’re exchanging on enterprise computing systems, but they may still have concerns about access to that information.

We’ve done deployments in enterprises with technologies that were observing situations in an office to see if you were interruptible for communications. To put people at ease with the sensors that were reading the environment, we put an on-off switch on the box so that, at any time, they could opt out completely. In the entire three-month time, nobody used that switch. You might take from that that it’s not important to have that capability, but it is so they have the comfort that they can gain control of their information.

Q: Interesting. Tell us some more about that deployment.

Begole: We did that at Sun Microsystems. It was connected to Sun’s instant-message system. We were using that to provide the presence information and the interruptability of the people on the IM service. That made it easier for remotely distributed teams to have awareness of when they could reach people: You could see not just whether somebody was online and in their office, but whether they were available for you to call them right now.

We took it a step further: If they weren’t available right now, we’d have the system predict when they were most likely to become available. That was based on statistical analysis of their presence patterns over time. That’s the kind of intelligence that ubiquitous computing expands.

Additional resources: VDC Conference 2011