Rogue Wave Software Blog

There is a lot of buzz in the industry today about the use of graphic cards for general computing, a.k.a. GP-GPU. Essentially, as clock speeds for CPUs have slowed down, we have all been scrambling to go parallel. CPU vendors have introduced dual-core, quad-core and more to increase performance, introducing what we at Rogue Wave termed the Multi-core Dilemma.

In addition, many people have been looking at specialty hardware for additional threads. One of the most interesting ones that has gained a lot of attention lately is the graphical processing unit (GPU). These have been used for years as graphics accelerators for video games and other media.

Recently people have been using them for general purpose computing since they are so good at crunching numbers (after all, rendering graphics is all about advanced math). This led to the term GP-GPU (general purpose graphical processing unit). It also happens that this hardware is very parallel. A typical consumer grade graphics card has about 128 threads. That’s a lot of calculations in a small space - no wonder they are so attractive. And for certain applications, it’s not uncommon to see anywhere from 10 to 30x throughput increase over a dual core CPU.

However, the software development environment for GPUs has several problems:
1. GPU hardware is difficult to program. This is improved from a few years ago, but it’s still much more difficult than a typical CPU environment and lacks the robust tools we’re all used to.
2. APIs for this hardware are proprietary to the vendor hardware. This is something we hear on a regular basis as an inhibitor to adopting GP-GPU.

And new development isn’t the only thing - probably more important right now is how to make existing code run here without rewriting everything.

All of this gets to the heart of parallel computing in general. The progress of software development in general depends on our ability to do parallel computing, and do it well. GP-GPU programming is a window into the world of challenges - and opportunities - that lay ahead.

Abstraction of concurrency from software application logic

(a.k.a: “I feel the need… the need for - Concurrency…”)

From Monolith to Component Architectures

In the olden days of computing, everything was combined into a single lump of software - including operating system functions, application logic, data, user presentation. After some time, we realized that creating a separation between the hardware and the software application would be useful, and the operating system was born. Some time later, we realized that managing the data was a distinct task, and databases became a separate entity. Some time after that, we decided that it would be a good idea to split out the user interface, and the era of client/server began.

So it went, the software industry continued to evolve our architectures into more componentized and modular arrangements.

Architecting for Concurrent Computing

Now that multi-core architectures are common and the need for concurrency in software architectures well understood, the next question is how best to architect our applications and how best to structure development organizations to support them. For the moment, let’s talk about the development organization. In the past, concurrency was a task limited to edge cases, but now ubiquitous multi-core hardware is making it much more common.

There are two ways to handle this. First, train all your software developers to be experts in concurrency (yikes…). Second, have concurrency specialists to focus on making your applications parallel. Since training all of your software developers to be experts in concurrency seems daunting, it would seem that the second option is better. But if concurrency is now required through significant portion of your application architecture, how can only a few engineers or architects be responsible for it?

The answer lies in abstracting the concurrency model from the application logic. While this may not be possible for all aspects of your concurrency model, it certainly should be for some - especially for well-defined services (in the SOA definition of the word). Services can be run in multiple instances across multiple threads and multiple cores (even multiple servers) to achieve a significant degree of concurrency without rewriting the code inside the service.

To the extent that you can do this, you can allow your application developers to focus on application logic and your concurrency experts to focus on concurrency. In addition, you can gain quite a bit more flexibility to your application architecture. The more your concurrency is abstracted, the easier it is to change without affecting the application logic. It’s really just an extension of the idea of loose coupling.

The Concurrency Model

This means that the application developer does not have to be the primary owner of the concurrency model. The application developer is able to focus on the application, and a concurrency expert can design about the concurrency model, just as a DBA does with the data model - I wouldn’t be surprised if we start to see something like a Concurrency Model Architect (CMA?).

Anyway, the whole thing relies on being able to separate your concurrency model from your application logic. More on that later.

Patrick

Joe Pruit posted a blog responding to some thoughts from Rogue Wave on C++ in 2008. We know that not everybody sees C++ in the same way we do, but we issued the press release was to challenge some of the conventions of how developers and architects perceive C++. Joe’s comments are worth reading, and are also worth responding to.

Enterprise applications do widely use Java and .NET, no question. Managed languages are the right tool for the job for a wide variety of applications. C++ however, (plus C and other native languages) continues a solid, and in many cases, growing presence in several areas:

High performance: for applications that require low latency and/or low memory usage, a large number of architects are choosing C++ in favor of managed languages. These are common in Financial Services, Military and many other applications. An interesting recent example is the team from Carnegie Mellon that won $2mm in the DARPA Urban Challenge for building an intelligent robotic car. According to the project lead, “Everything we did was written in C++.”

Embedded: For embedded and mobile devices, one of the fastest growing areas in computing, C++ is the language of choice over both Java and .NET. Lower memory, tighter power and heat limits and other requirements make C++ a natural choice for optimized application development. According to the Gartner Dataquest report ‘User Survey Analysis: Embedded Software Development Tools and RTOS, North America, 2006′, “For application development, C and C++ are the most popular development languages. Surprisingly, Java usage dropped in 2006.” (Daya Nadamuni, 13 September 2008)

Existing apps: And, of course there are billions of lines of existing mission critical applications built on C++ in enterprises around the world.

These are almost all mission critical, and many are also legacy. In my experience, many if not most mission critical applications are also legacy. My favorite quote on this: years ago, one of my dev managers once quipped that the definition of legacy is “anything that has gone into production…”

As far as the overall viability of the language, there are a few interesting points worth considering:

1. C++ developers are commanding strong salaries, in many cases higher than developers with Java and .NET. I don’t know for sure, but I suspect it’s a combination of C++ resurgence and a smaller number of C++ developers available.

2. Universities are starting to reconsider their move to teaching computer science students in Java. Many universities continue to teach in C++ so that students have a solid foundational understanding of how systems work. Some professors contend that teaching Java has contributed to a decline in computer science skills.

3. The language has a vibrant (and broad) standards community and continues a solid evolution. The C++0X standards effort is creating the next version of the language. The proposed enhancements include modern concepts from Java and elsewhere, but still maintain what makes C++ unique and different.

Although Java and .NET continue to have significant mindshare for mainstream applications, C++ is the language of choice for many architects in new development projects - probably more than most people think.

It appears as if the latest way to find more processing power is heading into the mainstream. Both Nivida and AMD have GPU cards dedicated to processing instead of graphics. The popular book series GPU Gems has even released a third generation of the series that contains quite a bit of information and examples using the CUDA architecture. However, if you’ve looked at CUDA you may have had a Bud Light commercial moment like I did and said, “Dude…”. The years of not writing code may be skewing my view on it, but to me this is not a simple API. It seems that without easier to use higher level tools, GPU processing might be restricted to the uber-brains of software engineering that do matrix math in their head for fun. Now I don’t want to single out CUDA, because Brook doesn’t seem likely to win any Easy Button awards either.

What is clearly needed is an abstract API on top of both vendor cards, that lets C++ developers write code without a huge learning curve. That’s an easy statement to make, but a lot of complexities arise. I have been asking some of our customers about what they think an API like this should look like, what level of complexity to hide and not hide, etc. While there is some consensus, there is also just as much differing opinion. The only obvious answer seems to be that people want to take advantage of GPUs, and they’re looking for a way to make it easier for them to do so. If you have strong feelings on what you would like to see, please let them be known.

It was our second year participating in the OOP conference in Munich last week.  This conference focuses on aspects of modern software engineering, so as you can imagine, it is heavily infused with SOA technologies.  I gave two talks, one about modernizing C++ applications, and the other on creating a service grid.  In my talks I focused on the challenges of maintaining performance characteristics when moving from a monolithic application to an SOA, while also dealing with distributed computing issues that may not have been previously relevant.  Both drew a good number of people and several of them came by our booth later to discuss their situation and how it would fit in with what I discussed. 

I was a bit surprised that there were a good number of people that said they have problems dealing with large XML files.  We call this VLM (Very Large Messaging) and we are very familiar with the issues surrounding it.  The most common issue has to do with memory consumption.  Typical DOM based parsers use about 6 times the size of the original XML file in memory.  When you start dealing with large files, that quickly becomes a problem.  The other main issue people are having is rooted in performance.  Parsing large files is time consuming, especially when unexpected things like garbage collection kick in.  We have been solving this problem for a while now with our HydraSDO for XML product.  It’s very fast being written in C++, provides a native Java API as well that utilizes shared memory so as not to impact performance, and uses a non-extractive, indexed parsing model that gives a 1.5 times original XML document size memory footprint. 

I’m excited for the opportunity to help these people with the large XML file problems they’re having.  If you’re having similar issues, let me know and we can get you some quick help.

I am very happy to announce the General Availability of HydraSDO for Databases 1.0.  We already have a “Java Edition” so this completes the set by providing support for the C++ SDO API.  The Service Data Object specification is particularly important for database access because it is the only industry standard API designed specifically for accessing data in Service Oriented Environments. HydraSDO for Databases provides a Data Access Service (DAS) for relational data that is built on SourcePro DB. This of course means that it is very, very fast – we expect it to be the fastest available in the market. It also means that existing SourcePro DB users can confidently migrate their database applications to a Service Oriented Environment. The database tools provided mean that there is no database access programming required.  HydraSDO for Databases also integrates seamlessly with HydraSCA. This is particularly important because it can be expected that relational data will be a core element of applications built using a Service Component Architecture, just as it has been in older application architectures such as client-server. HydraSDO for Databases is freely available for evaluation at our Download Center. 

I am pleased to announce the General Availability of HydraSDO for XML 2.2. As the product matures and gains more widespread use, some important use cases are emerging: 

Parsing Very Large XML Documents - The industry trend of increasing large XML documents has resulted in unexpected problems with applications slowing down due to slow parsing times and increased memory usage. HydraSDO for XML includes an XML parser that has been designed to quickly parse very large XML documents, which provides an immediate boost in application performance. Using very large XML documents to share data between applications is sometimes referred to as Very Large Messaging - VLM. As a rough guide, an XML document is considered large when it is over 10 MB and very large when it is over 100 MB. The XML schema complexity is also, of course, an important factor. The problem with most XML parsers is that, unlike HydraSDO for XML, they do not scale linearly.

Efficient XML Parser Memory Usage - One of the special characteristics of the XML parser that is shipped with HydraSDO for XML is that is optimized for low memory usage. This can provide an immediate performance enhancement for some applications as well as generally reducing hardware resource requirements. In extreme cases, for very large XML documents, it can prevent applications from crashing due to the unexpectedly excessive memory usage during parsing.  As a rough guide, depending on the XML document complexity, HydraSDO for XML uses about half the memory of a typical parser.

Standardized Access for Custom Data Formats - Writing data access code for custom data formats can be time consuming and can require specialist knowledge and skills. The HydraSDO SDK can be used with HydraSDO for XML to develop the necessary custom DAS for reading and writing custom data. Providing the single, standard SDO API in both Java and C++ for disparate custom data formats saves development time and costs.   

SDO DataObject Streaming - With HydraSDO for XML, you only have to parse an XML document once to take advantage of the ability to stream the SDO DataObject between computers. Using this capability, you remove the need to parse the document repeatedly while maintaining the same simple XPath-based API to work with the data (this feature is called Distributed SDO).  

Sharing Data Between Java and C++ Applications -  HydraSDO for XML uses the SDO DataObject to efficiently share data in memory between Java and C++ applications. Depending on the nature of the shared data, the feature works well for tightly coupled applications where it significantly reduces the memory footprint compared with other methods such as SOAP or CORBA (this feature is called Shared Memory Access - SMA).

Vertical Industry XML Document Handling - the internal HydraSDO for XML test suite includes a wide range of standard industry XML documents, particularly financial services. The test suite is exceptionally extensive because Rogue Wave Software has a long history of providing high performance XML parsers aimed at enterprise developers with requirements for support for specific industry XML formats.  

Service Data Objects (SDO) Standard - SDO is the industry standard for data access in Service Oriented Architectures (SOA). The SDO standard provides access to disparate data formats through the common SDO API, which is available in both Java and C++.  SDO is the data access standard for Service Component Architecture.

HydraSDO for XML 2.2 is available for download at the Download Center.

Two New York University professors, Dr. Robert Dewar and Dr. Edmond Schonberg, have written an article in the Journal of Defense Software Engineering about computer science courses neglecting basic skills, in particular in the areas of programming and formal methods.  The professors’ opinions have attracted discussion in places such as Slashdot and other popular Web sites since they have taken particular exception to the recent emphasis on Java in computer science courses.

The professors provide brief overviews of the educational benefits of various programming languages, including C and C++:

Why C Matters
C is the low-level language that everyone must know. It can be seen as a portable assembly language, and as such it exposes the underlying machine and forces the student to understand clearly the relationship between software and hardware. Performance analysis is more straightforward, because the cost of every software statement is clear. Finally, compilers (GCC for example) make it easy to examine the generated assembly code, which is an excellent tool for understanding machine language and architecture.

Why C++ Matters
C++ brings to C the fundamental concepts of modern software engineering: encapsulation with classes and namespaces, information hiding through protected and private data and operations, programming by extension through virtual methods and derived classes, etc. C++ also pushes storage management as far as it can go without full-blown garbage collection, with constructors and destructors.

What perhaps makes the professors’ opinions more credible is that their concerns are also commercial since they develop software commercially:

As founders of a company that specializes in Ada programming tools for mission-critical systems, we find it harder to recruit qualified applicants who have the right foundational skills. We want to advocate a more rigorous formation, in which formal methods are introduced early on, and programming languages play a central role in CS education

As the head of Rogue Wave Software’s professional services group, I’ve noticed that many of the younger engineers working in some of our customers are less skilled in C++ than their older colleagues.  While we’re happy to help our customers by filling in the skills gap on projects, it’s still a longer term worry because every programming language needs well educated and skilled developers. Teaching C++ in universities is a topic that I’ve been thinking about for some time. I’m particularly interested in what Rogue Wave can do to help with fundamental C++ skills, like promoting the use of the C++ Standard Library in universities and perhaps looking at the practicalities of making Rogue Wave’s products available for use in computer science courses. 

Rogue Wave Software congratulates our customers, JackBe Corporation and seeMore Technologies, who have been honored in InfoWorld’s 2008 Technology of the Year Awards. Both JackBe and seeMore are innovative ISVs that have included Rogue Wave Software’s Service Data Object technology in their product offerings using HydraSDO for Databases.

JackBe has won the prize “Best Enterprise Mashup Platform” for Presto 1.3.1, which InfoWorld describes as:

JackBe Presto provides a sophisticated set of tools for mashing together your data on the server before delivering it to a JavaScript client. A dashboard delivery mechanism lets end users create their own mashups from data services on the Web, or consume pre-built mashups from the Presto server.

SeeMore has won the prize for the “Best Database Middleware” for the Virtual Database Server 2.8, which InfoWorld describes as:

This brilliant tool from seeMore Technologies will enable a large enterprise to gather its far-flung databases — regardless of their origins — under a single, relational roof. The Virtual Database Server seeks to provide access to just about any data source, even flat text files and highly structured COBOL databases, through standard ODBC, JDBC, or OLEDB interfaces.

Rogue Wave wishes JackBe, SeeMore, and all our customers continued success in 2008!

I’m very pleased to announce the General Availability of SourcePro Edition 10, a very special event for Rogue Wave Software.

SourcePro is our flagship product and the main reason why we can claim to be the market leader in enterprise C++. We are launching the tenth version of SourcePro - a significant milestone that very few application development products reach. It’s a testament to the quality of the product and a demonstration of Rogue Wave’s long term commitment to the product, especially given the recent market trends moving in favor of C++  - most notably, new language standards coming in C++0X and giving C++ the same status as Java in new SOA industry standards such as SCA and SDO.

The full GA version of the product is available for customers now and the evaluation version will be available on our Web site in February.