David Mizell

Early experiences with large-scale Cray XMT systems

Several 64-processor XMT systems have now been shipped to customers and there have been 128-processor, 256-processor and 512-processor systems tested in Crays development lab. We describe some techniques we have used for tuning performance in hopes that applications continued to scale on these larger systems. We discuss how the programmer must work with the XMT compiler to extract maximum parallelism and performance, especially from multiply nested loops, and how the performance tools provide vital information about whether or how the compiler has parallelized loops and where performance bottlenecks may be occurring. We also show data that indicate that the maximum performance of a given application on a given size XMT system is limited by memory or network bandwidth, in a way that is somewhat independent of the number of processors used.

High-performance computing applied to semantic databases

To-date, the application of high-performance computing resources to Semantic Web data has largely focused on commodity hardware and distributed memory platforms. In this paper we make the case that more specialized hardware can offer superior scaling and close to an order of magnitude improvement in performance. In particular we examine the Cray XMT. Its key characteristics, a large, global sharedmemory, and processors with a memory-latency tolerant design, offer an environment conducive to programming for the Semantic Web and have engendered results that far surpass current state of the art. We examine three fundamental pieces requisite for a fully functioning semantic database: dictionary encoding, RDFS inference, and query processing. We show scaling up to 512 processors (the largest configuration we had available), and the ability to process 20 billion triples completely in-memory.

Extending SPARQL with graph functions

Much of the early domain-specific success with graph analytics has been with algorithms whose results are based on global graph structure. An example of such an algorithm is betweenness centrality, whose value for any vertex potentially depends on the number of shortest paths between all pairs of vertices in the entire graph. YarcDatas UrikaTM customers use SPARQLs graph-oriented pattern-matching capabilities, but many of them also require a capability to call graph functions such as betweenness centrality. This customer feedback led us to combine SPARQL 1.1s query capabilities with classical and emerging graph-analytic algorithms (e.g., community detection, shortest path, betweenness, BadRank). With this capability, a SPARQL query can select a specific subgraph of interest, pass that subgraph to a graph algorithms for deep analysis, and then pass those results back to an enclosing SPARQL query that post-processes those results as needed. With the Summer 2014 Urika release, we have extended the SPARQL implementation with a graph-function capability and a small set of built-in graph functions. We describe our design approach and our experiences with this first release, including anecdotal evidence of dramatically higher performance. Built-in graph functions represent an important step in the maturation of graph analysis and SPARQL. As common motifs emerge from use cases, those motifs may be mapped to specific graph functions that can be highly tuned for much higher performance than will be possible for SPARQL. Identifying those motifs and developing the underlying graph functions to accelerate their execution is a topic of intense effort industry-wide. Graph functions merged with SPARQL provide a new mechanism by which third-party graph-algorithm developers may expose their algorithms to widespread use.

Experimental comparison of emulated lock-free vs. fine-grain locked data structures on the Cray XMT

Three implementations of a concurrently-updateable linked list were compared, one that emulates a lock-free approach based on a compare-and-swap instruction, one that makes direct use of the Cray XMTs full-empty synchronization bits on every word of memory, and a third that uses the XMTs atomic int_fetch_add instruction. The relative performance of the three implementations was experimentally compared on a 512-processor XMT. The direct implementation approach performed up to twice as fast as the other two approaches under conditions of low contention, but the three implementations performed about the same when the amount of contention was high.

How Do We Solve Human Factors for VR and AR Applications

Virtual reality (VR) and augmented reality (AR) systems are reaching sufficient maturity that some systems are being used on a regular basis by users and others are close to implementation. There are limitations, however, that have prevented many systems from being truly useful for users. An important limitation is the lack of understanding of human factors issues, such as human perceptual and cognitive limitations, that affect the potential utility of VR or AR systems.

Towards a timed Markov process model of software development

The concept of a timed markov model is introduced and proposed as a means of analyzing software development workflows. A simple model of a single researcher developing a new code for a high performance computer system is proposed, and data from a classroom experiment in programming a high performance system is fitted to the model.