The top research stories of the week have been hand-selected from leading scientific centers, prominent journals and relevant conference proceedings. Here’s another diverse set of items, including an evaluation of multi-stage programming with Terra; a look at parallel I/O for multicore architectures; a survey of on-chip monitoring approaches used in multicore SoCs; a review of grid security protocols and architectures; and a discussion of the finer distinctions between HPC and cloud.
Multi-Stage Programming with Terra
A team of computer scientists from Stanford and Purdue Universities is investigating a new approach to multi-stage programming. Motivated by the increasing demand for high-performance power-efﬁcient applications and seeking to address the limitations of current generative programming techniques, the team developed a method that combines the high-level scripting language, Lua, with the low-level language, Terra.
According to the authors, it’s a beneficial arrangement that enables streamlined metaprogramming – a result of Lua and Terra sharing the same lexical environment – and enhanced performance afforded by Terra’s ability to execute independently of Lua’s runtime.
In a recent paper, the researchers describe the process of reimplementing multi-language systems within Terra, which they then compare with existing methods. They purposefully choose applications that are difficult to implement with a single language programming paradigm. Detailing the results of one experiment, they note that their Terra-based autotuner for BLAS routines performs within 20 percent of the ATLAS routine. The result reflects well on Terra, and they chalk up the discrepency to a register spill in Terra’s generated code that does not occur in ATLAS’s generated assembly. In the final analysis, they are satisfied that the approach leads to implementations that are simpler to engineer and achieve higher performance.
Going forward, the researchers have big plans for Terra, including integration with coprocessors, namely NVIDIA GPUs and Intel’s MIC architecture, which will provide additional performance for parallelized code.
Parallel I/O for Multicore Architectures
A group of researchers from the Supercomputing Center at Korea Institute of Science and Technology Information (KISTI) take on the subject of parallel I/O in a new research paper. The authors observe that with the increase in the average number of HPC system nodes, parallel I/O is more relevant than ever and so is collective I/O, the specialized parallel I/O that provides the function of single-file based parallel I/O. Furthermore, the move toward multicore computational nodes means that the roles of I/O aggregators, involved in engaging the communications and I/O operations, need to be re-evaluated.
The researchers note that there is already a body of work that focuses on improvement of the performance of collective I/O, but they state it is difficult to find a study regarding the assignment scheme for I/O aggregators in multicore architectures.
It was discovered that the communication costs in collective I/O differed according to the placement of the I/O aggregators, where each node had multiple I/O aggregators. The performance with the two processor affinity rules was measured and the results demonstrated that the distributed affinity rule used to locate the I/O aggregators in different sockets was appropriate for collective I/O. Because there may be some applications that cannot use the distributed affinity rule, the collective I/O scheme was modified in order to guarantee the appropriate placement of the I/O aggregators for the accumulated affinity rule.
The authors go on to detail an approach that demonstrates performance improvements in the face of complicated architectures. Their paper, “An Efficient I/O Aggregator Assignment Scheme for Multi-Core Cluster Systems,” is published in IEICE Transactions on Information and Systems by the University of Oxford Press.
On-chip monitoring of multicore systems-on-chip
A new paper put out by a Greek research duo documents the different on-chip monitoring approaches used in multicore systems-on-chip.
Their work stems from the premise that “billion transistor systems-on-chip increasingly require dynamic management of their hardware components and careful coordination of the tasks that they carry out.”
These diverse real-time monitoring functions are enabled via the collection of important system metrics: the throughput of processing elements, communication latency, and resource utilization at the application level.
“The online evaluation of these metrics can result in localized or global decisions that attempt to improve aspects of system behavior, system performance, quality-of-service, power and thermal effects under nominal conditions,” write the authors.
By providing a comprehensive survey of the available monitoring tactics the researchers aim to increase the understanding of architectural mechanisms that can be used in systems, which they believe will support further innovations in the development of adaptive and intelligent systems-on-chip.
The researchers are affiliated with the Technical University of Crete, in Chania, Greece, and their paper appears in ACM Transactions on Design Automation of Electronic Systems (TODAES) TODAES.
Revisiting Grid Security
Grid computing may have fallen out of fashion as a marketing term, but the distributed computing technologies that helped set the stage for today’s cloud are very much alive and well. And as with cloud or any IT system, security is a top concern for the grid community. It’s also the subject of recent paper from Malaysian researchers Saiful Adli Ismail and Zailani Mohamed Sidek. The duo provide a comprehensive review of current security issues in the grid computing arena.
In addition to presenting an overview of grid computing security, the paper also details types of grid security and depicts a prototypical architecture for grid computing security. The computer scientists wrote the paper with an eye toward shaping “future research in encryption, access controls, and other security solutions for the grid computing environment.”
As with most types of cloud architectures, grid represents a shared environment and as such it is necessary for the various parties to work together to overcome any risks, gaps and vulnerabilities that could jeopardize grid security.
The authors highlight and describe six main areas of grid security requirements: authentication, authorization, confidentiality, integrity, no repudiation and management. They also emphasize three essential services – authentication, authorization and encryption – without which grids are left unsecured and open to man-in-the-middle attacks.
While this paper mainly serves as an overview of best practices for grid security, the authors are also hoping to inspire other researchers to make contributions that advance grid security.
Research in the Cloud, Australian-style
A new paper came out this week detailing the activities of the NeCTAR Research Cloud, which has been running at the University of Melbourne since February 2012. During that time, the system has attracted more than 1,650 users and supported more than 110 projects.
In addition to offering a window into a successful “research cloud,” the authors make some interesting observations regarding the distinctions between HPC and cloud computing that are worth noting.
“HPC can be seen as the forerunner to cloud computing,” they write. “Rather than utilising local desktop computation resources, HPC allowed users to take advantage of available compute cycles on a massive remote resource. Cloud computing achieves a similar outcome. Both HPC systems and cloud computing are based on clusters of computers interconnected by some high-speed network, often managed by a dedicated additional (head) node.”
This isn’t the usual definition of (enterprise-leaning) cloud, which tends to run on general-purpose, vanilla infrastructure. Also, what makes it a cloud and not remote HPC or HPC as a Service?
Let’s go back to the document for the answer:
“Cloud computing and HPC differ in that HPC systems are predominantly task based whereas cloud computing is more often characterized as Infrastructure as a service (IaaS). On HPC systems, users submit tasks to a queuing system, which then allocates resources to the task as they become available. User tasks all run in the same software environment. Cloud computing on the other hand allows the users to develop VMs with their chosen software environment, which they then submit to an allocation system that allocates them the resources they need.”
The statement seems to be making reference to a heterogenous subset of resources which are provisioned on demand via the use of virtual machines. Fair enough. But there are still further distinctions to follow:
“The major differences are that on HPC systems, users are guaranteed exclusive access to the allocated resources for a limited time and sharing is accomplished by having tasks wait on a queue until resources become available, while in the Cloud resources are shared by being oversubscribed, but VMs are allowed to be persistent. This leads to the two systems having different best use situations.
“HPC, as the name implies, is most suited to well defined and bounded computational problems, whilst Cloud is most suited to ongoing continuous loads. Cloud systems also have the capability to add VMs in a dynamic fashion to cope with varying demand in a way that HPC systems find difficult, and this makes them suited to many collaborative activities where demand is hard to predict (Cohen et al. 2013; Suresh, Ezhilchelvan, and Watson 2013).”
The paper was written by Bernard Meade in collaboration with co-authors Steven Manos, Richard Sinnott, Andy Tseng and Dirk van der Knijff, all from the University of Melbourne, and Christopher Fluke from Swinburne University of Technology. It was presented this week at THETA Australasia: the Higher Education Technology Agenda in Hobart, Tasmania.