Rogue Wave Software: Blog for High Performance C++

Avik Sengupta from Lab49 wrote an interesting Guest View in the latest SDTimes about recent additions to Java to improve support for programming to multi-core hardware. 

When I started talking about the Multi-core Dilemma a few years ago the conventional wisdom in the Java community still held that we wouldn’t have to do anything different  - that Java would take care of it for us.  I even touched off a nice little flame war with a posting on The Server Side…

As Avik points out, Java does provide a powerful threading model that helps with multi-core, “but in practice it may not be so easy.“  With the addition of the concurrency package and the new fork/join, the tools for parallelism in Java are greatly improved.

These capabilities in Java, as well as new primitives and tools being added to C++ and other languages are geared at improving the realm of traditional multi-threaded programming for data and task parallelism.  But parallelism at a higher level of granularity - the business process level - is becoming more commonly used.  Business Process Parallelism is a technique that runs multiple instances of a business process, typically implemented inside of a service. This has multiple advantages, which I will cover in a subsequent post.

If performance and throughput are important for your application, consider where business process parallelism may be used in addition to data parallelism alone.

Axis2/C is a C based implementation of the Apache Soap engine, and builds on lessons learned from the Java version, Axis2/Java. It is written in C for platform portability, and has a pseudo object-oriented design approach¹. This involves putting operations in the header files and the data in the source files. Also macros are used extensively to hide complexity.

Rogue Wave’s HydraExpress product, on the other hand, is written in native C++, and the code it generates from a WSDL file is also C++. This means that the C++ standard library with its implementations of strings and collection classes are available to the user. HydraExpress is also supported across a wide range of platforms including Windows, Linux and UNIX.

For C++ developers who wish to easily create and deploy Web services, the pseudo object-oriented design approach and C language implementation of Axis2/C can present challenges when starting development. The HydraExpress C++ approach may present a coding style that is more familiar.

The example below is a comparison of the code required to implement a simple “Hello World” service in both Axis2/C and HydraExpress.

Axis2/C

adb_helloResponse_t* axis2_skel_GreetingService_hello(const axutil_env_t *env,
                                                      adb_hello_t* hello)
{
    /* TODO fill this with the necessary business logic */
    adb_helloResponse_t *response;
    axis2_char_t *input_message;
    axis2_char_t *output_message;

    /* Build the response adb */
    response = adb_helloResponse_create(env);
    if (response)
    {
        adb_helloResponse_set_return(response, env, output_message);
    }
    return response;
}

Hydra Express

std::string
GreetingPortTypeImp::hello(rwsf::CallInfo& callInfo,
                           const std::string& hellorequest_in)
{
    return std::string(’Hello from server ‘ + hellorequest_in);
}

References
1. http://wso2.org/library/252

History

For almost 20 years, Rogue Wave Software has been one of the world’s leading providers of C++ libraries and components. From an early time in our evolution, we have provided the most widely portable C++ standard library available - the “Rogue Wave C++ Standard Library”.

Rogue Wave SourcePro C++ (and its predecessor .h++ products) have supported building with the Rogue Wave C++ Standard Library and the “native” standard libraries (those that ship with each compiler) for years. Two years ago we donated the Rogue Wave C++ Standard Library to the Apache foundation. It is now an open source project known as the Apache C++ Standard Library.

Recent trends

The C++0X standard is one of the biggest things to happen in C++ development in quite a while (that may be the understatement of the day), bringing many exciting new features to the language. Rogue Wave has been active in the development of this new standard. Since most of the changes affect the C++ standard library, this means a heavy investment would be required to update the Apache C++ Standard Library for the new standard.

At the same time, other solid alternatives are available. As the C++ standard library specification became more stable, the API has become very consistent between the Rogue Wave/Apache C++ standard library and native C++ standard libraries. As a result, many people have already moved from our standard library to the native standard libraries.

Realizing that this would inevitably impact our ability to invest in our SourcePro, Hydra and Stingray products, we have determined that the best way for us to support our customers is to focus our effort on our core products and leave standard library development to others.

SourcePro C++ Edition 10 update 1 will be the last release to certify with the Rogue Wave/Apache C++ standard library. A 12 month obsolescence period begins with the shipment of Edition 10 update 1, during which customers use of the Rogue Wave/Apache C++ standard library will fully supported. At the end of this period, we will no longer certify SourcePro with Rogue Wave/Apache C++ standard library and cease development on the Rogue Wave/Apache C++ standard library itself.

Focus on Core Products

Our job at Rogue Wave is to make sure that our SourcePro, Hydra and Stingray customers continue to be successful, and this move is designed to help us to do just that. By dropping support for the Apache C++ standard library we are able to increase our investment in SourcePro. This gives us more time for ports, enhancements, bug fixes, as well as taking advantage of new C++ language features as they become available. I’m confident that this will result in a better overall experience for our customers.

Going forward

Rogue Wave encourages all of our customers to begin using native standard libraries. SourcePro will continue to be certified with the native standard library for each supported compiler. Rogue Wave software is committed to the success of our customers and the SourcePro product. We thank each of you for your business - please feel free to post a response to this blog with any comments you have on how we can improve your experience as a Rogue Wave customer.

By Patrick Leonard, VP Engineering & Product Strategy

All of the major computer hardware vendors have been moving to multi-core CPUs for several years now, creating the situation that we refer to as the Multi-core Dilemma, which I have written about for several years. Recently, more choices for parallel hardware have become available for enterprise applications.  This will lead to some great opportunities but will also require tricky decisions of software development organizations.

Some of the new multi-core hardware will look more homogeneous, like a group of CPUs. Some of the new multi-core hardware will start to look more heterogeneous, like a CPU surrounded by different specialized cores like GPUs (graphical processing units) and others. Both approaches are going to benefit the industry on the whole, but there are pros and cons for each that should be factored into your software development planning.  This is my breakdown of the hardware vendors’ strategy.

Intel and Sun are pursuing the homogeneous CPU multi-core strategy:

• Intel’s Larrabee project is a many-core CPU strategy that they argue will reduce (or eliminate) the need to use separate GPUs and other accelerators for general-purpose computing, although it seems likely that it could bear some similarities to GPUs in the areas of floating point and vector operations.  One of the main advantages of this approach is that it leverages the existing X86 instruction set.  Not everyone loves the X86 instruction set, but there are certainly huge benefits to keeping the existing toolchains (compilers, debuggers, profilers) that are already in place.  At Rogue Wave, we have tested multi-core Xeon systems with our Hydra product and see very good scalability with this approach for common business applications.
• Sun recently released Niagara2, their follow up to the industry-leading Niagara multi-core server.

IBM, AMD and nVidia are taking the heterogeneous approach:

• AMD, with their purchase of ATI, added GPU hardware to their offering, and has put “stream computing” and “accelerated computing” (formerly known as “Fusion”) at the center of their strategy, and has partnered with Rogue Wave as part of this strategy.  The vision here is basically fusion of CPU and specialized “accelerators” so that the hardware is more tuned to different use cases.  For example, CPUs are great at time slicing and scheduling, while GPUs are great at processing math in parallel.  AMD recently made a public embrace of the nascent OpenCL standard as a programming model for GPU.
• IBM, in partnership with Sony and Toshiba, has brought the CellBE processor to market.  The basic idea here is similar to AMD’s accelerated computing: specialized hardware tuned to different use cases all on a single chip.
• nVidia is focused on the GPU.  Focus has a lot of advantages; nVidia is ahead of AMD in getting GPU into the mainstream market (although this is still very early stage) and has a more robust API and tool environment with CUDA.  Many people in both industry and academic areas have reported significant throughput increases using nVidia GPUs for complex compute-intensive problems that are capable of running in a massively parallel environment. Rogue Wave is also working closely with nVidia and we have seen excellent performance using their hardware for compute-intensive parallel problems.

All of these strategies are pursuing a similar goal: increased throughput through parallel hardware.  All of them will require changes to existing software to take advantage of this increased compute power.  All of them will also require software developers to think differently about how they design software in the future.

We at Rogue Wave are very aware of what we have termed the multi-core dilemma.  The problem is simple:  multi-core chips require software concurrency to take advantage of the full processing power.  The solution can be very challenging, however, requiring developers to introduce threading or multi-process code into their applications.  We have been promoting the ability to achieve parallelism at a service level within our Hydra product line, but within SourcePro we have until now only provided a threading abstraction layer that still requires significant application refactoring if not used initially.

To help improve the ability for our customers to take advantage of multi-core architectures, we are currently investigating ways to introduce parallelism within some of our current SourcePro classes.  The easiest area to add parallelism “under the hood”, so to speak, is in areas where there is read-only access occuring.  For these cases, we maintain safety in performing parallel operations that hopefully would require no code changes for our customers.

To ensure that introducing parallelism where it previously didn’t exist will not cause issues with existing use of the products, we are looking to make activation of the parallel code occur from a switch type mechanism.  We could provide a new build flag, an environment variable or other options to allow the developer to easily test the new operations, and switch back to the existing implementations if necessary.

Areas we are looking at include search methods on RWCString, methods on collections for sorting and search with iterators, as well as new higher level parallel algorithms that we could add to SourcePro DB.  We are actively soliciting feedback from our customers on which classes and methods are used most frequently, as well as ideas on where parallelism could provide the most benefit.  Please comment with your ideas and interests to help us maximize the benefit from these new enhancements.

Where do we start to describe what Rogue Wave has to offer in the world of Services, Web Services, SOA or even SCA?

Firstly, it’s important to understand that Rogue Wave is a leading provider of C++ Technologies: “we make C++ look like Java”, thus helping to save the cost of implementing common programming tasks…

Secondly, it is useful to review a bit of history: When web technologies started to emerge, people turned to Java and Tomcat Servlets to create more advanced Web Interfaces. In some ways, this was the birth of J2EE & Application Servers, and one of the biggest challenges was, and still is, to integrate existing C++ server business logic with this new Java front end. People turned to JNI for in process communication or CORBA for out of process interaction.

Because those solutions can be seen as overkill, Rogue Wave offered an alternative strategy by providing a native C++ implementation of Servlets, named Bobcat that lets you directly connect your C++ to the web protocol. It may not be the best tool to create a full interactive Web GUI, but if you only have to create an HTML table from a “C++ derivative pricing computation”, spending days developing a JNI interface might not be your best way… And with “AJAX-like asynchronous web requests”, distributing them across heterogeneous nodes makes even more sense nowadays.

A few years later, during the proving grounds of XML, people were also struggling to find a good solution to “parse XML in C++”. Rogue Wave introduced XML Object Link, still the simplest C++ XML Binding solution for XML parsing. Put simply, give it a schema file (the description of what is expected in the XML data), and it will automatically generate all you need to parse, modify, create and save that data. There is no need to understand and explicitly program the parsing logic like for DOM or SAX. So if you are tasked to create a programming API to deal with a complex schema like FIXML, you ought to have a look at it.

Lastly, let’s look at the current offering:

You can’t purchase Bobcat or XML Object Link any more, but the same functionality is now available in HydraExpress, formerly known as LEIF. But Hydra Express is really a tool to create and consume web services from C++.

You start from a WSDL, and you can create a “C++ Proxy” (a class that lets you call the related service) or a “C++ Server Skeleton” (a class you can derive from to implement the service). HydraExpress also provides you with a runtime environment to deploy the newly created services. So if you have a WSDL, you can be up and running with a C++ implementation in minutes: If you have to create a new IFX interface, a new Pricing engine…etc… with logic in C++, HydraExpress is the tool for you.

After all, the Web Services promise is to make heterogeneous systems works together. So, contrary to popular belief, it doesn’t need to be all Java.

Creating independent reusable services is of great value, pretty easy to do (thanks to HydraExpress and equivalent Java technologies), but “connecting the dots” between them and making them interact has turned out to be trickier than expected.

There are a lot of reasons why building an application by “drawing arrows” in a BPM graphical tool is doomed to fail. One must be careful about Central Points of Failure, Bottlenecks, Queues, Dynamic Load Balancing, and Failover… Without these, one will fall into the same traps that led to the Myth “SOA is slow”.

For this, Rogue Wave uses HydraSCA.

HydraSCA lets you build C++, Java or Composite Services based on SCA. HydraSCA is used to implement customer solutions with a focus on performance from the get go. Dimensioning and load balancing services is a key element for achieving a performing Service Oriented Solution, and HydraSCA provides those capabilities through an advanced distribution mechanism, an optimized runtime, and a pipeline theory.

Lastly, HydraSCA relies on a standard data access technology called SDO that has triggered off-the-shelf independent products. One of them is HydraSDO for XML that lets you parse XML files using a dynamic interface (unlike Hydra Express which is static). In tests, HydraSDO for XML has been able to offer DOM like random access to data at a speed and memory consumption close to SAX.

Back when SOA was the new, big buzz word there was a lot of talk around the WS-* standards for Web services.  Our company and many other vendors providing products in the space were doing a lot of talking about which standards were relevant, when would they be needed, and how they would work within an enterprise.

 It’s been several years now since most of them were proposed, and from my experience with talking with our customers, there is not widespread adoption or even need.  The one exception to that statement would be WS-Security.  There is always a need for security, and at a basic level encryption when doing any type of messaging.  When speaking with enterprise architects and developers, security always enters the conversation at some point.  However, one that had a lot of talk in the early days but hasn’t turned out to show real demand is WS-Reliable Messaging.  We have found that most people would rather rely on their enterprise transport mechanism such as a queing or JMS implementation.  Is there real need out there for this standard and we’re simply not seeing it?

There are also standards like WS-Addressing (needed for WS-Reliable Messaging) and WS-Transaction.  Neither of these has come up in a conversation that I have had for at least a year.  Are these viable, necessary standards that vendors should strive to attain compliance to?  Are there other standards that are absolutely required to implement Web services within an enterprise environment?  I guess until the masses rise up and declare the need, they might just show up as another check-box item when evaluating vendor products.

FpML (Financial products Markup Language) is the industry standard protocol for complex financial products. It was first published in 1999 and is now managed by the ISDA (International Swaps and Derivatives Association). FpML is important because it is the XML specification for OTC (over-the-counter) derivatives and its use has increased substantially over the past few years, especially for interest rate and credit derivatives, according to a recent survey by the ISDA. The complete FpML specifications can be found on the FpML website.

Rogue Wave Software’s HydraSDO for XML product enables XML documents to be read and updated using the SDO (Service Data Objects) API which uses simple XPath notation. SDO is the industry standard for data access in a Service Oriented Architecture. HydraSDO for XML has extremely fast parsing capabilities and very low memory requirements, resulting in performance improvements for most applications. Both C++ and Java are supported, with shared memory access allowing a single copy of data to be accessed by both a C++ and a Java application.

The example below shows how a bond option FpML instance document can be read into memory, and data can be easily retrieved and modified using the Hydra SDO for XML C++ API. The instance document (bond-option.xml) is available from the FpML website.

Example

By Patrick Leonard, VP Engineering & Product Strategy

Recently I had the opportunity to address the Chicago chapter of ACM (Association of Computer Machinery) on the subject of parallel computing. In addition to giving me the opportunity to make a Star Wars reference or two,
it was a very interesting conversation on the subject. About a quarter of the attendees were from the financial services industry and close to half of the attendees are interested in using GPUs.

The main point of my talk was to give an overview on current trends in the industry and to discuss a model for parallel computing in software development. Most parallel programming has been focused at the task and data level with tools like OpenMP and MPI. Data parallelism continues to be very important, but I suggest that there is a higher level of granularity in parallel computing - Service Parallelism.

Service Parallelism is essentially the intersection of SOA and parallel computing. Rather than taking a loop or function inside of a program and making a parallel you take a whole service and run multiple instances of that service (loops can be parallel too, they are just running inside the service).

There are several advantages to this:

• If you already have services there is little to no recoding required.
• Changing service parallelism means a change in configuration not encode so ongoing maintenance is much easier.
• Service parallelism separates the parallel aspect of the application from the logic so your application developers don’t have to be experts in the parallel model.

If you are interested in a review of industry trends on multi-core CPU, GPU, and ideas for software parallelism, take a look at the slides on the Rogue Wave web site.

By Patrick Leonard, VP Engineering & Product Strategy

Intel recently announced that they are working on a new programming language specifically designed for multi-core CPU hardware - called ‘Ct’. Ct is ‘C’ for throughput, and is essentially the C programming language with extensions.

It is similar in many ways to CUDA from nVidia and Brook+ from AMD, although Ct is for CPUs and CUDA & Brook+ are for GPUs (see earlier post re: GPUs). This is likely to be a good thing for software developers who are working on getting existing and yet-to-be-written software to scale appropriately on multi-core hardware.

Ct uses the combination of a compiler and runtime to take much of the burden of parallelism from the software developer. For example, the basic tasking unit is a ‘future’, which can be executed now or later and receives data consistency guarantees from the runtime. You can find details on how it will work on Intel’s site.

It does, however, highlight again the split that has occurred in hardware design - all vendors are going multi-core/multi-thread, but some are taking more of a homogeneous CPU approach, and some are taking a more heterogeneous GPU (accelerator) approach.

For software engineers, this means productivity challenges (”how do I get my existing code to run on GPUs, how do I get it to scale on multi-core CPUs”) as well as portability issues (”I don’t really want to maintain code written in CUDA, Brook+ and Ct, even though they are all variants of C”). This is all related to the Multi-core Dilemma that I have written about previously on the Intel Blog site and elsewhere.

Rogue Wave’s ‘Hydra’ product uses Service Parallelism to address the Multi-core Dilemma on CPUs, and we have worked with Intel a great deal on this, as it is complementary to Ct and other Intel technologies like TBB.

We are also working with both nVidia and AMD on Project “Gazelle” to address GPUs. “Gazelle” will generate optimized code for nVidia and AMD GPUs, and could do the same for Intel Ct in the future to ease migration for existing applications.