Last week at SC12 in Salt Lake City, Convey Computer pulled the lid off its MX big data-driven architecture designed to shine against graph analytics problems, which were at the heart of the show’s unmistakable data-intensive computing thrust this year.

The phrase high performance computing was, without surprise, found everywhere last week. However, increasingly, we were seeing another moniker pop up with far more frequency—high performance analytics. While SAS was first to game in snapping up the term for its own in-memory analytics push, everyone from IDC to IBM and now Convey is snatching up the catch-all umbrella name for big data power.

For Convey’s CEO, Bruce Toal, high performance analytics refers to the use of advanced, power-conscious and performance-optimized systems for unclogging programmatic and system-centered issues to perform against graph-type problems. These aren’t just found in internet search and Web 2.0 use cases, either. Toal told us that bioinformatics, fraud detection pros and government agencies have all found cause to explore this emerging class of problems—and so too have the powers that be at SC events where the Graph 500 ranking of data-intensive systems have been drawing ever-larger crowds.

The company’s Graph 500 showpiece features the capability to run tens of thousands of threads of execution coupled with what they call a “smart memory system” that can atomically perform in-memory calculations. Backed with the claim that it can scale to 32 terabytes of physical memory, Convey says the MX Series can exploit massive degrees of parallelism while efficiently handling hard-to-partition algorithms. 

During an extended sit-down at the show, we talked about why his mantra of “smarter computing for better analytics” goes far beyond a catchy marketing phrase, especially for those who have graph problems that they’re working against a traditional cluster paradigm.

The problem with price, power and performance are exaggerated for data-intensive applications if you’re looking at solving those on a high performance cluster, explained Toal. He pointed at various systems on the TOP500 and the Graph 500 as representative of the advantages of purpose-built data-intensive architectures over even the most efficient cluster computing systems.

For example, as you can see in the graphic below, for the growing breed of graph-based problems, it’s hard to rationalize the power and price investments in a system like TACC’s Dell cluster, which weighs in at 512 nodes and 6,000-plus cores—but 8 billion versus 15 billion edges per second. That aside, we’re talking about a $12 million system that burns through an estimated 358 kilowatts.

On the flip side, he says that Convey’s new big data approach is stuffed with memory, consumes less than 1,000 watts of power and runs less than $100K while hitting the 15 billion mark in terms of traversed edges per second (gigateps). Others in the same ballpark and with similar architectures, including Cray’s XMT, are in the 11 billion gigateps range. Further, he told us that for both standard cluster systems and the data-intensive focused systems, the reduction in power and floorspace alone is an attractive element.

At the heart of the company’s approach to solving big data analytics, power and performance problems is the mighty FPGA, which Toal claims addresses the tricky switching needs of data-intensive applications. Throw in an OpenMP-based programming environment and some “personality” and Convey can claim to have cooked up something worth a closer look.

Toal said that the mission was to speed graph analytics, specifically, while leveraging momentum in the x86 ecosystem via their partnerships with Intel and FPGA slinger Xilinx. He said that by integrating their hybrid-core approach to that environment by sharing memory let them build a system that could be reconfigurable and reprogrammable on the fly, allowing Convey to assign various “personalities” that are fine-tuned to specific application areas.

For instance, on the bioinformatics front, there are a lot of wasted parts in the computation that led to gross inefficiencies and performance bottlenecks, all of which can be solved through stripping and refining subtle system elements. To put that in context, when working with genetic sequencing, there are a total of four nucleotides that make up the keys to DNA. These nucleotides can be represented in 2 bits, so when doing 2-bit arithmetic on a 64-bit architecture, there’s significant waste that can be tidied up nicely with some personality that’s designed around the relatively small 2-bit need. By tailoring how the system chews out 2-bit operations to put the DNA puzzle pieces together, they can eek some extra performance, and thereby efficiency.

Another of Convey’s multiple personalities bears a government cryptographics face. In this case, the problem lies in efficient pattern-matching, whereas with basic graph analytics—the same type used to evaluate the top performers on the Graph 500 charts—it’s all about pointer-chasing where one node points to another, showcasing the ability of the FPGA approach in keeping pace.

“Part of the power of our architecture is that we built a memory system that lets you jump between different points in memory very efficiently. We call this scatter-gather so instead of getting a whole cache line, you get the piece in memory you’re looking for.”

Despite his claim to superiority, Toal was liberal in his praise for what Cray’s been working on with its XMT architecture and uRiKA graph appliance. He says what’s unique about the MX100, however, is that the memory system on the coprocessor is the backbone for that scatter-gather capability so highly prized in big graph analytics. He described the atomic memory operators, which are not so unlike the XMT’s which leverage tag bits to allow fine-grained synchronization down to every 64-bit word, leaving an extra bit that allows a lock—an aspect that is critical when you’re doing thousands of threads that are all trying to work on the same data.

More specifically, Toal explained the personality in the context of the overall programming environment, which is designed to wick away some of the nasty tangles of working with FPGAs, dealing with lock bits and messing extensively with scheduling headaches.

“We have a personality that’s loaded in that’s a multiple instruction, multiple-data personality framework,” said Toal. “Each one of the little thread units has a simple RISC-like instruction set and uses lock bits for synchronization—with the whole idea being to provide low latency.” Further, all the thread scheduling is done in hardware instead of the operating system software.

So, for example, when you spawn 10 threads to start working independently, when one is thread is finished and you want to switch to another thread on that core, the operating system usually gets involved, which is at the thousand-plus thread level, creates some serious scalability walls. “We built it into the personality in hardware so it’s fast and efficient so when a thread is stalled, it automatically gets swapped out by the personality,” Toal explained.

Another important component to the architecture is the OpenMP angle, which they’ve implemented in the MX’s low-level runtime routines to let users go from single-node to parallel performance with a simple pragma. Toal insists it’s as easy as taking a multithreaded application, running it through their OpenMP-flavored library, and having it run their instruction set on the hardware instead of in the operating system software.

In general, Toal feels that the types of problems that are being addressed by the broader-use Hadoop use cases that abound and approaches like his own and Cray’s is that they want to get an edge on the hyper-advanced real-time analytics workloads.