What’s Next For OpenACC?

The OpenACC parallel programming standard emerged late last year with the goal of making it easier for developers to tap graphics process units (GPUs) to accelerate applications. The scientific and technical programming community is a key audience for this development. Jeffrey Vetter, professor at Georgia Tech’s College of Computing and leader of the Future Technologies Group at Oak Ridge National Laboratory, recently discussed the standard. He is currently project director for the National Science Foundation’s (NSF) Track 2D Experimental Computer Facility, a cooperative effort that involves the Georgia Institute of Technology and Oak Ridge, among other institutions. Track 2D’s Keeneland Project employs GPUs for large-scale heterogeneous computing.

Q: What problems does OpenACC address?

Jeffrey Vetter: We have this Keeneland Project -- 360 GPUs deployed in its initial delivery system. We are responsible for making that available to users across NSF. The thinking behind OpenACC is that all of those people may not have the expertise or funding to write CUDA code or OpenCL code for all of their scientific applications.

Some science codes are large, and any rewriting of them -- whether it is for acceleration or a new architecture of any type -- creates another version of the code and the need to maintain that software. Some of the teams, like the climate modeling team, just don’t want to do that. They have validated their codes. They have a verification test that they run, and they don’t want to have different versions of their code floating around.

It is a common problem in software engineering: People branch their code to add more capability to it, and at some point they have to branch it back together again. In some cases, it causes conflict.

OpenACC really lets you keep your applications looking like normal C or C++ or Fortran code, and you can go in and put the pragmas in the code. It’s just an annotation on the code that’s available to the compiler. The compiler takes that and says, “The user thinks this particular block or structured loop is a good candidate for acceleration.”

Q: What’s the impact on scientific/technical users?

J.V.: We have certain groups of users that are very sophisticated and willing to do most anything to port their code to a GPU -- write new version of code, sit down with an architecture expert and optimize it.

But some don’t want to write any new code other than putting pragmas in the code. They really are conservative in that respect. A lot of the large codes out there used by DOE labs just haven’t been ported to GPUs because there’s uncertainty over what sort of performance improvement they might see, as well as a lack of time to just go and explore that space.

What we are trying to do is broaden the user base on the system and make GPUs, and in fact other types of accelerators, more relevant for other users who are more conservative.

After a week of just going through the OpenACC tutorials, users should be able to go in and start experimenting with accelerating certain chunks of their applications. And those would be people who don’t have experience in CUDA or OpenCL.

Q: Does OpenACC have sufficient support at this point?

J.V.: PGI, CAPS and Cray: We expect they will start adhering to OpenACC with not too much trouble. What’s less certain is how libraries and performance analysis tools and debugging tools will work with the new standard. One thing that someone needs to make happen is to ensure that there is really a development environment around OpenACC.

OpenMP was a decade ago -- they had the same issue. They had to create the specification and the pragmas and other language constructs, and people had to create the runtime system that executes the code and does the data movement.

Q: What types of applications need acceleration?

J.V.: Generally, we have been looking at applications that have this high computational intensity. You have things like molecular dynamics and reverse time migration and financial modeling -- things that basically have the characteristic that you take a kernel and put it in a GPU and it runs there for many iterations, without having to transfer data off the GPU.

OpenACC itself is really targeted at kernels that have a structured block or a structured loop that is regular. That limits the applicability of the compiler to certain applications. There will be applications with unstructured mesh or loops that are irregular in that they have conditions or some type of compound statements that make it impossible for the compiler to analyze. Users will have to unroll those loops so an OpenACC compiler has enough information to generate the code.

Some kernels are not going to work well on OpenACC whether you work manually or with a compiler. There isn’t any magic. I’m supportive, but trust and verify.

Aberdeen Group Analyst Offers Tips on Protecting Virtualized Environments

There’s a lot riding on server virtualization, and the risk of disruption only increases as IT shops deploy more virtualized applications on fewer physical machines. A loss of a single box can bring down multiple applications, so organizations that hope to preserve the availability of apps need to protect the environments in which they run. Dick Csaplar, senior research analyst of storage and virtualization for Aberdeen Group, has been looking into these issues. He recently discussed steps enterprises can take to address downtime concerns.

Q: What got you interested in the topic of protecting virtualized environments?

Dick Csaplar: Last year, we found through our survey process that we passed the milestone where, now, more than 50 percent of applications are virtualized. You now have to start thinking about applications being virtualized as the rule, not the exception. With virtualization, you have greater server consolidation and density, so a single server’s worth of downtime impacts more applications than in the past.

The other thing that was of interest: I was at Digital Equipment Corp. back in the day, and the PDP 8 was kind of the first corporate-affordable minicomputer. That led to the growth of the corporate data center concept for even midsized corporations. The concept of downtime was co-birthed at that moment. Today, more business processes are computer-based, so downtime costs companies more than ever. Protecting against computer downtime has been, and continues to be, a major focus of IT and will be for the foreseeable future. Things happen, and you have to be prepared.

Q: Are there steps organizations should take as they go about protecting virtualized settings?

D.C: The first thing you have to think about: It’s not one-size-fits-all. You just don’t say, “I’m going to put all applications on a fault-tolerant server to get maximum uptime.” Quite frankly, it’s expensive and unnecessary. You want to tier your applications -- which ones really require high levels of uptime and which ones, if you are down for a half a day, are not going to kill an organization.

The highest-level tier is the absolutely mission-critical applications like email and database- and disaster-recovery applications. It is worth investing in a high level of uptime because when the email system goes down, for example, people stop working. But with test and development environments, even if you lose them, there was no data in there that was really corporate-critical. Most organizations -- about 60 percent, our research shows -- don’t bother to protect their test and dev applications.

And there’s a middle tier of apps where you’ve got to do the math: Is downtime protection worth the investment?

Secondly, you need to have an idea of the cost of downtime. That sets the right level of investment for your disaster recovery and backup strategy. If the cost of downtime is measured in hundreds of dollars, obviously you can’t justify spending tens of thousands of dollars to keep applications up. If it is measured in tens of thousands of dollars, you should invest a relatively large amount of money in your downtime protection.

The cost of downtime varies by application. Ballpark it. Get it to an order of magnitude. Get a sense of what those things cost, and that will guide you to the appropriate level of protection. You are right-sizing your solution.

Q: What are the technology alternatives?

D.C.: On the software side, the hypervisors themselves have high-availability technology that is embedded. It monitors applications and, if it detects an app is not performing, it will restart the application on a new server. It’s very cheap. But you do lose the data in transit; any data in that application is gone.

Then you have software clusters. You have to pay for that, but it’s better protection in that the data gets replicated to other locations. Then there is the whole area of fault-tolerant hardware: fault-tolerant servers.

Q: Can an enterprise reuse their existing application protection technology in a virtualized environment, or do they have to use technology geared toward virtualization?

D.C.: That depends on the level of protection you want and what you currently have. One of the best technologies for application protection is image-based backup. It takes a picture of the entire stack -- the hypervisor, the application and the data. That image can be restarted on any new server.

Image-based backup tends to work better in highly virtualized environments. That doesn’t mean that the more traditional backup and recovery tools don’t work. They can, but you have to specifically test them out.

And that would be another thing to consider: having a formal testing policy. About half of the survey respondents we’ve researched don’t have a regular testing program for backup and recovery. They back up all of this stuff, but they don’t know if it would work in an emergency. There has to be a formal testing process at least quarterly.

Q: Any other thoughts on protecting virtualized environments?

D.C.: We are talking more about business processes here than we are talking about tools. We’re talking about best practices for keeping apps up and running, and most of them have to do with good data protection processes.

A lot more needs to be done than just throwing technology at it. You have to do your homework and you really have to know your business.

Photo: @iStockphoto.com/Kohlerphoto

Yes or No on NoSQL?

The rise of non-relational database technologies has engaged a growing IT audience. In order to understand what’s gained when employing non-SQL approaches, we spoke with renowned database expert, David McGoveran, who has consulted on bleeding-edge distributed applications and database solutions since 1976 when he founded Alternative Technologies.

Q: How does NoSQL fit in the universe of database approaches?

David McGoveran: “NoSQL” means different things to different people. Early on, it was portrayed as “not SQL.” More recently, that’s been tempered somewhat and is considered “not only SQL.” The big picture that holds this community together is a rebellion against the RDBMS [relational database management system] solution providers. RDBMS solutions are often expensive to purchase and maintain. They have lots of features for which most developers will never see a use, a kind of commercial software code bloat. And there’s a difference between a pure programmer’s IT perspective (i.e., rapid solution delivery) versus the data modeler’s (i.e., long-term asset creation).

The NoSQL community can be seen as an outgrowth of the anti-relational movement that came about with object-oriented programming. They share lots of the same issues and concerns.

Q: Please explain one of those issues.

D.M.: One issue has to do with the level of data organization. An RDBMS contains facilities for managing data, whereas a database is just an organized collection of data or, more generally speaking, an arbitrary container for data called a data store. With a data store, you’re dealing with low-level physical access and implementation (e.g., a file system). A fair number of the NoSQL solutions are at the data-store level. Hadoop, for instance, is focused on the functionality necessary to distribute data of lots of types and offers high availability. File organization is not as important in Hadoop as is data distribution and access over a large number of nodes. The NoSQL community is concerned with being able to cheaply (e.g., with little up-front design effort) scale up to thousands of servers and nodes, perhaps geographically distributed, or thousands of control processors, often maintaining some partitioning or “sharding” of the data. Support for MapReduce algorithms is often considered essential, but its proper use can be tricky.

Q: Are all NoSQL solutions data stores?

D.M.: No. There are a variety of DBMS solutions in the NoSQL camp, but the one thing they won’t embrace is SQL, about which NoSQL is pretty rigid. NoSQL insists that “one size does not fit all,” meaning there’s no one approach to data management. Some DBMS solutions that would be classed as NoSQL allow programmers to access the data stored in a way that will best meet their application needs. Their physical organizations are application-specific. Among them are graph (linked) databases, text databases, columnar databases, stream-oriented databases, and key-value (aka associative) databases.

Q: From an application perspective, what kind of application should use NoSQL?

D.M.: Consider a NoSQL solution if your application involves collecting masses of data, and you can’t develop a data model for it, or if you can’t physically organize the data and develop a logical schema and metadata before you start to use it. Often the data is organized in non-uniform ways or for human consumption rather than computer processing. Eventual data copy consistency is often more important than insuring the data satisfies business rules and relationships. Social media is a good example. In such applications, you want to find data or mine relationships -- consider Amazon, LinkedIn, Google, eBay, Netflix, etc. -- in ways that are not traditional data-management problems.

Q: From an architectural perspective, what kind of application should use NoSQL?

D.M.: The best architecture for high availability and scalability depends heavily on product capabilities and intended use. If application objectives change too much over time, your implementation might break. It’s inherently brittle and requires upfront investment. For relatively stable IT environments, RDBMS solutions work great, because those products were designed to meet the needs of availability, scalability and reliability in such applications. But when you don’t have a lot of predictability about how the database is going to change and grow, the kinds of data, how many nodes you’re going to have, what types of nodes, nor how many processors you’ll need … all of a sudden, a relatively low-level simple solution that’s open-source and low-cost appears very attractive to a developer who is being hit over the head every morning for not having delivered a solution.

Q: How should an enterprise think about using NoSQL?

D.M.: I suggest considering a NoSQL solution if any of the following are true:

  • First, when discovery of relationships is more important than consistent processing and specific data results.
  • Second, if the data processing is meant to be inductive (e.g., suggestive) rather than deductive (i.e., precise).
  • Third, when the application is changing very fast, data complexity is great (variety or amount).
  • Fourth, if physical issues, like big data or a high degree of parallelism, are more crucial than data integrity. You must be willing to throw away data consistency in favor of performance and scalability.
  • Fifth, if you have a mission-critical one-off application for which a fixed data organization is ideal, in which case the costs and risks may be lower than licensing a vendor’s RDBMS or trying to force an open-source RDBMS to fit the need.

Who’s in Charge of Multicore?

Like just about every other technology, multicore processors have an industry organization to help create best practices and guidelines. For developers, following The Multicore Association (MCA) can be a convenient way to keep up with what processor manufacturers, OS vendors, universities and other ecosystem members are planning a year or two out. MCA president Markus Levy recently spoke with Intelligence in Software about the organization’s current initiatives.

Q: What’s MCA’s role in the industry? For example, do you work with other trade groups and standards bodies?

Markus Levy: Multicore is a huge topic with many varieties of processors, issues and benefits. It boils down to the target market and, specifically, the target application to determine whether to use a homogeneous symmetrical multiprocessing processor or a highly integrated system-on-a-chip with many heterogeneous processing elements. The Multicore Association is and will be biting off a chunk of this to enable portability and ease of use.

With this in mind, we primarily aim to develop application program interfaces (APIs) to allow processor and operating system vendors and programmers to develop multicore-related products using open specifications. It’s important to note that The Multicore Association doesn’t currently work with other trade groups or standards bodies. We never intend to compete and/or develop redundant specifications.

Q: Developers work with whatever hardware vendors provide at any given time. In this case, that’s multicore processors. How can keeping up with MCA help developers understand what kind of hardware and software might be available to them in a year, three years or five years down the road? For example, what are some current association initiatives that they should keep an eye on?

M.L.: Good question. Notice that the MCA membership comprises a mixture of processor vendors, OS vendors and system developers. The main benefit for processor vendors is to support current and future generations of multicore processors. In other words, it makes it easier for their customers to write their application code once and only require minor changes as they move to another generation processor.

The OS vendors are also utilizing the MCA standards to enhance their offerings, and customers are requesting it. System developers are actually using our open standards to create their own proprietary implementations that are optimized for their needs.

We currently have a Tools Infrastructure Working Group (TIWG) that is defining a common data format and creating standards-based mechanisms to share data across diverse and non-interoperable development tools, specifically related to the interfaces between profilers and analysis/visualization tools. Actually, in this regard, the TIWG is also collaborating with the CE Linux Forum on a reference implementation for a de-facto trace data format standard that TIWG will define.

Our most popular specification to date is the Multicore Communications API (MCAPI), and the working group is currently defining and developing refinements and enhancements for version 2.0. MCAPI is now implemented by most OS vendors, quite a few university projects, as well as versions developed by system companies.

We’ve recently formed a Multicore Task Management API (MTAPI) working group that is focused on dynamic scheduling and mapping tasks to processor cores to help optimize throughput on multicore systems. MTAPI will provide an API that allows parallel embedded software to be designed in a straightforward way, abstracting the hardware details and letting the software developer focus on the parallel solution of the problem. This is already turning out to be quite popular with fairly extensive member involvement. It’s an important piece of the puzzle that many developers will be able to utilize in the next one to two years.

Q: Multicore processors have a lot of obvious advantages, particularly performance. But are there any challenges? The need for more parallelism seems like one. What are some others? And how is The Multicore Association working to address those challenges?

M.L.: There are many challenges of using multicore processors. Parallelizing code is just one aspect. Again, it also depends on the type of multicore processor and how it is being used. While the MTAPI is focused on the parallel solution, the MCAPI is critical to enable core-to-core communications, and our Multicore Resource management API (MRAPI) specification is focused on dealing with on-chip resources that are shared by two or more cores, such as shared memory and I/O.

Q: The MCA website has a lot of resources, such as webinars and a discussion group. Would you recommend those as a good way for developers to keep up with MCA activities?

M.L.: The webinars provide good background information on the projects we have completed so far, so I recommend these as starting points. The discussion group is very inactive. Better ways to stay up on activities include:

  • Subscribing to the MCA newsletter. This comes out every four to eight weeks, depending on whether or not there is news to be reported.
  • We also have special cases where nonmembers can attend meetings as guests. They can contact me for assistance.
  • Attend the Multicore Expo once a year, where members go into depth on the specifications. Plus, other industry folks present on various multicore technologies.

Photo Credit: @iStockphoto.com/4kodiak

Is Ruby on Rails a Crown Jewel?

Ruby on Rails has established itself as one of the favorite development environments for Web developers. As it expands into the universe of mobile devices, tablets and other platforms, the question arises whether Ruby will displace other development languages and environments. We spoke with Ruby on Rails founder and CEO, David Heinemeier Hansson, to examine its cross-platform prospects.

Q: With tons of options for Web development, why is Ruby on Rails so much more popular than Java or Python?

David Heinemeier Hansson: I think Ruby on Rails struck a chord with lots of developers for a number of reasons. One, we started from day one with the concept of a full-stack framework. You don’t need to go through a long evaluation process of dozens of different frameworks to figure out which database mapper to use, which template language, etc. It’s all in the box.

Two, Ruby is a big step forward in terms of pleasurable development compared with Java, PHP and many other old-school platforms. The language itself is simply a joy to use, and it didn’t take long for people to recognize that. You simply have more fun and you’re able to be more productive using Ruby than most other mainstream programming languages.

Three, we have critical mass. The Ruby on Rails communities took a while to grow, but now that they’re here and in great numbers, it’s a self-accelerating process. People pick Ruby on Rails because other smart developers have picked it. Thus, you attract more and more people.

When you combine those three factors, you get something that’s a material step forward compared to other mainstream platforms -- and very appealing.

Q: Each of these platforms has its own unique set of requirements for memory footprint, performance, form factor, security and so on: embedded devices, mobile devices, multicore, parallel programming, high-performance computing and cloud. How suitable could Ruby on Rails be for each of these?

D.H.H.: I deal mostly with Web programming, which spans mobile, multicore, high performance, and cloud, and I believe it’s a fantastic fit for that. A few years ago, before people were educated on the alternatives, there was a big hoopla around Ruby’s then lack of green threads. It turned out to be largely a nonissue as Web applications work great running as separate processes instead of threads. So we’re able to take advantage of all the cores you can throw at it for concurrency, which in turn gives you access to basically unlimited throughput.

Yes, there are still hotspots in certain applications where it can make sense to use something else. But 99.9 percent of all applications written will never arrive to that point. It is far more important that you spend your time creating a desirable application as fast as possible than trying to preemptively worry about what will happen if you’re in the 0.1 percent.

Q: Is the Ruby on Rails runtime performance and memory footprint competitive with development in languages such as C++?

D.H.H.: Definitely not, but for a very large class of problems, that doesn’t matter. Most applications fail or succeed not on the basis of how much memory they use, but on whether users are interested. It’s far easier to iterate your way from early prototype to something users are interested in if you’re using a platform like Ruby on Rails. The fruit of progress is that we can choose to talk about more important things than memory pointers .