Compilers and More: OpenACC to OpenMP (and back again)

By Michael Wolfe

June 29, 2016

In the last year or so, I’ve had several academic researchers ask me whether I thought it was a good idea for them to develop a tool to automatically convert OpenACC programs to OpenMP 4 and vice versa. In each case, the motivation was that some systems had OpenMP 4 compilers (x86 plus Intel Xeon Phi Knights Corner) and others had OpenACC (x86 plus NVIDIA GPU or AMD GPU), and someone wanting to run a program across both would need two slightly different programs. In each case, the proposed research sounded like a more-or-less mechanical translation process, something more like a sophisticated awk script, and that’s doomed from the start. I will explain below in more detail how I came to this conclusion. However, there is a germ of a good idea here, so I will follow with a summary of a research idea that someone could start with.

Why Simple Conversion is Insufficient

OpenMP was first released in 1997 (initially for Fortran). It started as a group of multiprocessor vendors (including SGI, IBM, Sun, HP) who essentially agreed to spell parallel do the same way. Each vendor already had its own set of parallel directives, but agreeing on a spelling and meaning would allow programs to be ported across systems. OpenMP was actually the second attempt to get vendors to agree on such a spelling; the Parallel Computing Forum predated OpenMP by some years, and many of the ideas proposed by the PCF were later used in the development of OpenMP. OpenMP has been very successful and is widely adopted in the scientific and technical computing community.

Agreement on both the spelling and meaning for OpenMP was important. Agreement on the meaning became agreement on the implementation, and to improve efficiency on the systems of the day, the OpenMP committee chose a careful, prescriptive definition of the parallel constructs. OpenMP is thread-centric, and describes how many threads are created and how the parallel work is distributed across those threads. This approach was appropriate as a solution for the machines of the day, where a multiprocessor had only single- digit parallelism, vector machines were waning, and thread startup costs were prohibitively high. However, these constraints no longer apply.

OpenACCOpenACC was released in 2011, specifically to support parallel computing on accelerators, including GPUs, as well as other parallel systems. I was involved in the earliest meetings, and from the very start we worked to design a solution that would be effective for a wide variety of target systems: host+GPU; host+Clearspeed accelerator; host+Cell processor; host+Digital Signal Processor; host+Intel MIC (then, the prototype Knights Ferry, now the Xeon Phi); AMD Fusion APUs with a CPU and GPU on a single die, as well as multicore CPUs. To support such a wide range of targets, OpenACC took a more descriptive approach, to use the directives to describe properties of the program, allowing the compiler and runtime to choose runtime values appropriate for the target system. For instance, where a multicore system may only have 4 or 8 or 16 cores, implying that only so many parallel threads are sufficient, a highly parallel GPU may require hundreds or thousands of threads to efficiently utilize the hardware. Encoding those values into a parallel program seemed like a recipe for program obsolescence.

In 2013, OpenMP 4.0 was issued with support for accelerators and with much similarity to OpenACC. Both OpenMP 4 and OpenACC have data directives and clauses, and parallelism directives. The data directives are used when compiling for a host+accelerator system where the accelerator has a separate physical and/or virtual memory, and control data movement between system and device memory. The data directives and clauses in the two specifications are mostly coherent, meaning it is mostly feasible to mechanically convert OpenACC data directives to OpenMP 4, and vice versa.

OpenMPIt’s a very different story for the compute directives. OpenMP was designed in a world with only a few SMP processors on each system, so it was reasonable to include a wide variety of synchronization primitives. OpenMP includes atomic operations, critical sections and ordered critical sections, single and master sections, barriers, doacross dependences between loop iterations, parallel sections, tasks and task dependences, and explicit management of locks. Most of these are nonscalable, either limiting the amount of parallelism that can be expressed, or will run afoul of Amdahl’s Law limiting the amount of benefit you get when running in parallel. Of these, OpenACC includes only the atomic operations. This restricts the kind of program you can write using OpenACC, but it also means the programs you write will be more scalable to future systems. That means converting an OpenMP program containing these constructs to OpenACC is a nonstarter.

But it goes much deeper than that. Even for the simple cases where OpenMP and OpenACC intersect rather closely the two specifications have different definitions and implementations. As described in more detail in an earlier article about parallel loops, OpenMP is defined in terms of threads and how the work is shared across threads. If the program specifies using 32 threads, then that’s how many you’re going to get. Someone will point out that the implementation can in fact reduce that number, but there’s no provision for increasing it. If you have a target with more parallelism available (think Intel Xeon Phi x200 Knights Landing with up to 72 cores and 4 hardware threads per core), the compiler or runtime can’t just bump that up to 288 threads. It can’t even use the parallel directive to help the compiler silently auto-parallelize within an OpenMP thread; the directives state that the program can’t have any data races across threads, but it says nothing about data races across loop iterations scheduled to the same OpenMP thread. This is the key reason that OpenMP needed the simd directive and clause; even saying omp parallel for doesn’t tell the compiler that it’s safe to vectorize the loop, so a new directive was added.

OpenACC, on the other hand, does require that a parallel loop be data-race free across loop iterations. This gives the compiler a significant amount of freedom. Just saying acc parallel loop allows the compiler to generate multicore code, as well as vector or SIMD code for targets which support that. This is both simple and powerful, and enables the user to write a single version of their his or her program that can be compiled for several different targets.

Many programmers are unwilling to give that control to the compiler, and it’s certainly true that smart programmers are always going to be smarter than any compiler. However, compilers are tireless. Programmers are not, and architectures change faster than programs. We need a programming model that encourages scalable parallel programming, and that allows that parallelism to be remapped across a wide range of hardware parallelism, such as what we see on the immediate horizon and beyond.

But this isn’t a diatribe about the advantages of OpenACC or OpenMP over the other, it’s about converting from one to the other. If I want a tool to translate an OpenMP parallel loop to an OpenACC parallel loop, the conversion is no longer mechanical. The tool must determine whether the loop is truly a data-race-free parallel loop, and if not, either run it sequentially, or somehow (magically) convert it into a loop that is. Either way, such a tool requires much deeper analysis and more work than the researcher probably wants to undertake.

Going the other way, converting OpenACC to OpenMP, sounds easier. Once you know it’s a parallel loop, it’s certainly safe to write that loop using OpenMP. However, there are two parts to the parallelism in an OpenACC loop: identifying the parallelism, and mapping the parallelism onto the hardware. OpenMP 4 and OpenACC each have three levels of parallelism. OpenMP has teams of threads which can execute simd operations, where OpenACC has gangs of workers which can execute vector operations. Many OpenACC programs use the directives to identify the parallel loops, and leave much of the mapping to the compiler. As mentioned above, a loop prefixed with acc parallel loop, with no other clauses, will run in parallel, and depending on the target, it may run across gangs, or both gangs and vector lanes, with the decision made by the compiler. With nested loops, the number of possible mappings increases. An OpenMP program, however, uses a different directive for parallelism across teams (distribute) from parallelism across threads (for or do) and from SIMD parallelism (simd). So, an OpenACC program with three loops:

 

would have to be more explicit in OpenMP:

Moreover, when targeting a simple multicore CPU, you may want a completely different program. Multicore compilers currently ignore the teams and distribute directives, if they parse them at all yet, so that level of parallelism is lost. It may be better to write this program differently, collapsing the two parallel loops:

In any case, the conversion in either direction is no longer mechanical, and hence, in my opinion, any attempt to do a simple bidirectional translation is a waste of effort.

The Research Proposal

However, when reconsidering these proposals, I decided that there is a kernel of a good idea here. The goal is to be able to write a single program that runs across as wide a variety of systems as possible, and the availability of coherent OpenMP and OpenACC implementations are a problem. I think someone could do a one-way translator, from OpenACC to OpenMP, and learn enough from that process to deliver novel research results, and produce a useful translator as well. For those systems that have OpenMP but don’t (yet) have OpenACC, such a translator can be immediately useful. As hinted at in the last section, the research component is to create a target-specific parallelism mapping scheme, so that the parallelism in the program gets exploited appropriately for that target. There could be a learning process, or a user-specification of the mapping, or predicates based on program characteristics such as data access patterns.

So, what follows is a prototype of a research proposal for creating such a translator. Feel free to copy and edit these ideas to create your own proposal. If you want, you can send me your own proposal; I’ll keep it confidential, make suggestions, and if it looks good, I’ll even be glad to write an endorsement. If you are a program manager at a funding agency and receive such a proposal, I’ll be glad to review it and will be as direct and (brutally) honest as I always am.

Cover Page

Parallel Programming Model Translator

The University of Intelligent Beings

Earth, Sol System

Project Summary

This project will create a tool that converts Fortran, C and C++ programs containing OpenACC [1] directives into target-specific OpenMP [2] directives. The main artifact of the project will be a source-to-source program conversion tool, named MPACCT (pronounced “impact”) that will be distributed and available for use by HPC programmers when targeting their programs for different architectures.

The major research goal of the project is to explore, evaluate and prioritize the various ways that the parallelism in a program, expressed in OpenACC, should be targeted for different parallel systems. To augment the parallelism expressed in OpenACC directives, we will implement various classical compiler loop autoparallelization strategies, as is common in commercial OpenACC compilers. The generated output program, expressed in OpenMP, will include specific mappings to teams, threads and simd operations. The generated output will depend on: (a) characteristics of the input program, such as data reference patterns and loop structures; (b) features of the target system, such as whether it is a multicore or host+accelerator and the parallelism profile of the multicore and/or accelerator; (c) features of the target compiler, such as the program structures for which it is optimized and basic capabilities.

An ancillary research goal is to develop a characterization and representation of the parallelism profile of a target system that we can use in MPACCT. This will include such obvious items as the number of cores, hardware threads and preferred vector or SIMD length. We expect to include other features, such as information about the cache hierarchy and any hardware synchronization features. An artifact from the project will be a published representation of the parallelism profile for the variety of parallel systems that we use in our experiments. The parallelism profile for the target system will be an additional input to MPACCT.

Another ancillary research goal is to study whether we can develop a language that would allow an expert developer to control the parallelism mapping process in MPACCT. To be successful, the MPACCT mapping feature must be entirely exposed, with no hidden decisions. The language will allow the developer to control the mapping based on characteristics of the program and the target machine. We plan on an extensible language to allow for future systems that need additional program characteristics which we can’t yet envision.

Finally, a fourth goal is to develop parallel programming, architecture and compiler expertise in our students, and to use this to improve parallel systems education.

Project Description

Future high-end computing systems are being designed with much higher node parallelism than we have available today. We see systems like Cori at NERSC being installed with a Intel Xeon Phi Knights Landing processor in each node, with support for four hardware threads per core and 512-bit SIMD instructions. We have designs in place for the CORAL Summit and Sierra supercomputers at ORNL and LLNL, with multiple IBM OpenPOWER CPUs and multiple NVIDIA Volta GPUs in each node. In these future systems, exploiting parallelism on a node will be critical to getting the best performance.

In HPC, inter-node parallel programming is dominated by MPI, and that’s not likely to change in the near future. This project does not attempt to replace or augment MPI across nodes. Many current HPC programs use MPI within a node as well. This will become less suitable in the future. As the on-node parallelism increases, the number of MPI ranks would increase, reducing the memory available per rank and increasing the amount of data being uselessly copied between ranks on the same node. Moreover, systems with GPU accelerators have two additional levels of parallelism (CPU in parallel with the GPU, and parallelism on the GPU itself) which MPI simply does not address.

On-node parallelism in HPC mostly uses OpenMP today. Classical OpenMP (OpenMP 3.1 and earlier) is well understood and available on all high-end computer systems. The later versions of OpenMP (4.0 and 4.5) include support for accelerators, such as GPUs and DSPs, managing data placement and parallel computation on the accelerator. However, there are few implementations of this and fewer mature ones.

OpenACC was developed by a subset of OpenMP members to drive the development of parallel programming directives suitable for a wide range of target systems, and specifically including accelerated systems. Many of the target features of OpenMP, such as the data directives, were first developed in OpenACC.

However, having two standards presents a problem for programmers. If they are programming for Cori using the Intel compilers, they will be using OpenMP 4 directives, probably without any target features since Knights Landing is not an accelerator. If they are programming for Titan today or Summit or Sierra tomorrow, they may well be using OpenACC directives with the PGI or other compilers, to control parallelism on the GPUs as well as the CPUs. If they are programming for their cluster at home, they may be using OpenMP with the GCC compilers, with much less parallelism to worry about. And, to make matters worse, they probably have to support all those targets at once, since they are developing locally but want production runs on whatever big system on which they can get time. Moreover, their application is being developed and extended over a period of years, and years from now the high-end systems may well be something completely different.

We will address this problem by creating a program translation tool, which we call MPACCT, that translates OpenACC programs into target-specific OpenMP programs. The translation uses four inputs:

  1. the OpenACC directives, and specifically the parallelism directives;
  2. additional parallelism discovered using classical compiler autoparallelization;
  3. characteristics of the program, including data reference patterns and program structures; and
  4. features of the target system, such as number and types of cores, availability and capability of SIMD instructions, threads per core, cache sharing patterns, and more.

Objectives

The primary objective and artifact is MPACCT, the translator itself. This tool will be based on <name your favorite compiler infrastructure here>, and will support Fortran, C and C++ <or some subset thereof> programs. In basic mode, the MPACCT driver will be given the input program and the local configuration file. The configuration file describes the target system features that control the translation process, and the target compiler. The driver will invoke the MPACCT translator to generate a target-specific OpenMP program. Then the driver will invoke the target compiler to generate an object or executable file. In this way, the MPACCT driver will be a drop-in replacement for any compiler driver (gcc, icc, pgcc, llc, xlc, and so on).

A secondary objective is to characterize and represent the parallelism profile of a range of target systems. For multicore systems, the parallelism profile will include at least the number of cores, hardware threads per core, SIMD capability, and cache configuration. For GPU-accelerated systems, it will include the number of CPU- core analogs, the depth of multithreading, the SIMD (or SIMT) width, and hardware parallelism support. We expect to identify other important system features as we develop more program optimization techniques that depend on the target systems. We plan to publish a table describing the parallelism profile for each of the target systems on which we experiment.

A third objective is to derive a language to control the MPACCT translation and optimization process. We expect the translation to depend on target system features and on program features. What we want is a way to give predicates or weights on the code optimization and generation process based on program features and target system features. This idea is still in its infancy at this point.

Significance

The most significant result will be showing that a large number of programs can be ported across widely different node architectures by just recompiling. This kind of portability is highly desirable, but there is a great deal of skepticism as to whether it is feasible. In particular, recent presentations have stated that the only way to maintain performance across different systems is to use conditional compilation (ifdef preprocessor statements) with code or directives specific to each architecture. Quoting from the NERSC 2014 Annual Report [3], “In 2014, NERSC and Cray established a joint Center of Excellence to help users port and optimize target applications that will run on Cori…” Imagine what will happen when those codes need to be run on a different architecture. Imagine instead what would happen if they could be written so porting was mostly tuning a translator and recompiling.

We expect our results to also feed into the language design, compiler and system architecture communities.

The process of porting codes across various systems will allow us to explore new language primitives that allow more flexibility when generating the output code. The mechanisms used in MPACCT can then be reproduced in other open source or commercial compilers. Finally, when porting programs between two or more system architectures, some program features will perform better on one or the other. As we explore the translator optimizations, we will be uniquely positioned to comment and give feedback about the importance or lack thereof of certain architectural features for HPC.

Present State of Knowledge

Compilers for languages like OpenMP 3.1 are mature and well developed. Compilers for a more flexible language like OpenACC are less mature. There are commercial OpenACC compilers supporting multiple GPU targets and multicore processors as well. However, outside of a few workshop presentations [4] and marketing literature, there are few details about how these compilers are implemented.

Other relevant compiler technology is mature, such as that used in classical parallelizing compilers [5]. We expect to build on that work as we develop our translator. Our contribution is not the development of new program analysis methods, but how to use the knowledge from the program and compiler analysis to map the program optimally to the target architecture.

Development Plan

Year 1:

  • Collect the infrastructure to do the program analysis: program intermediate representation, parallelization analysis; build the code generator; define the interface between the parallelism mapping phase and the code generator.
  • Study the target system architectures and collect the key architectural differences.
  • Get initial access to the target systems.
  • Collect small, medium and large benchmark programs; use the small programs to build an initial performance training set, to collect performance of variants of a program on the target systems.

Year 2:

  • Design and build a set of program transformations in the code generator; build a test engine that will test correctness of each transformation in any legal combination with any other transformation.
  • Build a test engine to test each possible program parallelism configuration on any target system; collect performance information and correlate that with architectural features; design how the parallelism mapper will drive the transformation and optimization process.
  • Formalize the architectural feature set; design an architectural description language; implement a scheme to input that language to MPACCT.

Year 3:

  • Compare MPACCT performance on various systems with native compiler performance, and with manually-tuned applications.
  • Continue to tune the parallelism mapper.
  • Look at new architectures, and demonstrate that our architectural description language can be used to tune MPACCT for a previously unseen architecture.

Experimental Procedures

Our experiments are essentially all performance measurements. We will use standard procedures for measuring performance, such as ensuring the system is otherwise unloaded, running every program three times and saving middle measurement, running with multiple host compilers and optimization levels.

Results from Prior Support

You’re pretty much on your own here.

References

  1. OpenACC-Standard.org, The OpenACC Application Programming Interface, Version 2.5, October 2015; http://www.openacc.org.
  2. OpenMP Architecture Review Board, OpenAP Application Programming Interface, Version 4.5, November 2015; http://openmp.org/wp.
  3. 2014 Annual Report, National Energy Research Scientific Computing Center.
  4. Michael Wolfe, “Implementing the PGI Accelerator Model,” in GPGPU-3, Pittsburgh, Penn., March,2010; http://dl.acm.org/citation.cfm?id=1735697.
  5. Michael Wolfe, High Performance Compilers for Parallel Computing, Addison-Wesley, 1996.
  6. Cheng Chen, Canqun Yang, Tao Tang, Qiang Wu, Pengfei Zhang, “OpenACC to Intel Offload:Automatic Translation and Optimization,” National Conference on Computer Engineering andTechnology 2013, July 20-22, 2013, Springer-Verlag, pp. 111-120.
  7. Galen Arnold, Alexander Calvert, Jeffery Overbey, Nawrin Sultana, “From OpenACC to OpenMP 4: Toward Automatic Translation,” in XCEDE16, Miami, Florida, July 17-21, 2016.

Biographical Sketches

I am an individual!

Budget

Four smart and hard-working graduate students plus one staff member for three calendar years. Travel to three conferences each year, including SC; other relevant conferences include ASPLOS, CGO, HPCA, ICPP, ICS, IPDPS, ISC, ISCA, SIGMicro, PACT, PLDI, PPoPP, and various workshops attached to these.

Equipment

This work will require workstations for the staff, and access to a variety of high-end systems. Since we are not evaluating parallelism across nodes, we don’t expect to require access to many nodes of any one system, but we do want as wide a variety of target systems as is feasible.

Summary

Have fun! I look forward to seeing the results of your research.

 

michael-wolfeAbout the Author
Michael Wolfe has been a compiler developer for over 40 years in both academia and industry, and has been working on the PGI compilers for the past 20 years, and if he were still in academia, he would be working on this proposal in earnest. The opinions stated here are those of the author, and do not represent opinions of NVIDIA. Follow Michael’s tweek (weekly tweet) @pgicompilers.

Subscribe to HPCwire's Weekly Update!

Be the most informed person in the room! Stay ahead of the tech trends with industy updates delivered to you every week!

Kyoto University ACCMS Implements Fine-grained Power Management

September 19, 2018

Data center power management is a ubiquitous challenge and in few places is it more so than at Kyoto University Academic Center for Computing and Media Studies (ACCMS)) where power consumption limits were imposed followi Read more…

By Staff

What’s New in HPC Research: September (Part 1)

September 18, 2018

In this new bimonthly feature, HPCwire will highlight newly published research in the high-performance computing community and related domains. From exascale to quantum computing, the details are here. Check back every Read more…

By Oliver Peckham

House Passes $1.275B National Quantum Initiative

September 17, 2018

Last Thursday the U.S. House of Representatives passed the National Quantum Initiative Act (NQIA) intended to accelerate quantum computing research and development. Among other things it would establish a National Quantu Read more…

By John Russell

HPE Extreme Performance Solutions

Introducing the First Integrated System Management Software for HPC Clusters from HPE

How do you manage your complex, growing cluster environments? Answer that big challenge with the new HPC cluster management solution: HPE Performance Cluster Manager. Read more…

IBM Accelerated Insights

A Crystal Ball for HPC

People are notoriously bad at predicting the future.  This very much includes experts. In the Forbes article “Why Most Predictions Are So Bad” Philip Tetlock discusses the largest and best-known test of the accuracy of expert predictions which show that any experts would do better if they make random guesses. Read more…

Nvidia Accelerates AI Inference in the Datacenter with T4 GPU

September 14, 2018

Nvidia is upping its game for AI inference in the datacenter with a new platform consisting of an inference accelerator chip--the new Turing-based Tesla T4 GPU--and a refresh of its inference server software packaged as Read more…

By George Leopold

House Passes $1.275B National Quantum Initiative

September 17, 2018

Last Thursday the U.S. House of Representatives passed the National Quantum Initiative Act (NQIA) intended to accelerate quantum computing research and developm Read more…

By John Russell

Nvidia Accelerates AI Inference in the Datacenter with T4 GPU

September 14, 2018

Nvidia is upping its game for AI inference in the datacenter with a new platform consisting of an inference accelerator chip--the new Turing-based Tesla T4 GPU- Read more…

By George Leopold

DeepSense Combines HPC and AI to Bolster Canada’s Ocean Economy

September 13, 2018

We often hear scientists say that we know less than 10 percent of the life of the oceans. This week, IBM and a group of Canadian industry and government partner Read more…

By Tiffany Trader

Rigetti (and Others) Pursuit of Quantum Advantage

September 11, 2018

Remember ‘quantum supremacy’, the much-touted but little-loved idea that the age of quantum computing would be signaled when quantum computers could tackle Read more…

By John Russell

How FPGAs Accelerate Financial Services Workloads

September 11, 2018

While FSI companies are unlikely, for competitive reasons, to disclose their FPGA strategies, James Reinders offers insights into the case for FPGAs as accelerators for FSI by discussing performance, power, size, latency, jitter and inline processing. Read more…

By James Reinders

Update from Gregory Kurtzer on Singularity’s Push into FS and the Enterprise

September 11, 2018

Container technology is hardly new but it has undergone rapid evolution in the HPC space in recent years to accommodate traditional science workloads and HPC systems requirements. While Docker containers continue to dominate in the enterprise, other variants are becoming important and one alternative with distinctly HPC roots – Singularity – is making an enterprise push targeting advanced scale workload inclusive of HPC. Read more…

By John Russell

At HPC on Wall Street: AI-as-a-Service Accelerates AI Journeys

September 10, 2018

AIaaS – artificial intelligence-as-a-service – is the technology discipline that eases enterprise entry into the mysteries of the AI journey while lowering Read more…

By Doug Black

No Go for GloFo at 7nm; and the Fujitsu A64FX post-K CPU

September 5, 2018

It’s been a news worthy couple of weeks in the semiconductor and HPC industry. There were several HPC relevant disclosures at Hot Chips 2018 to whet appetites Read more…

By Dairsie Latimer

TACC Wins Next NSF-funded Major Supercomputer

July 30, 2018

The Texas Advanced Computing Center (TACC) has won the next NSF-funded big supercomputer beating out rivals including the National Center for Supercomputing Ap Read more…

By John Russell

IBM at Hot Chips: What’s Next for Power

August 23, 2018

With processor, memory and networking technologies all racing to fill in for an ailing Moore’s law, the era of the heterogeneous datacenter is well underway, Read more…

By Tiffany Trader

Requiem for a Phi: Knights Landing Discontinued

July 25, 2018

On Monday, Intel made public its end of life strategy for the Knights Landing "KNL" Phi product set. The announcement makes official what has already been wide Read more…

By Tiffany Trader

CERN Project Sees Orders-of-Magnitude Speedup with AI Approach

August 14, 2018

An award-winning effort at CERN has demonstrated potential to significantly change how the physics based modeling and simulation communities view machine learni Read more…

By Rob Farber

ORNL Summit Supercomputer Is Officially Here

June 8, 2018

Oak Ridge National Laboratory (ORNL) together with IBM and Nvidia celebrated the official unveiling of the Department of Energy (DOE) Summit supercomputer toda Read more…

By Tiffany Trader

New Deep Learning Algorithm Solves Rubik’s Cube

July 25, 2018

Solving (and attempting to solve) Rubik’s Cube has delighted millions of puzzle lovers since 1974 when the cube was invented by Hungarian sculptor and archite Read more…

By John Russell

AMD’s EPYC Road to Redemption in Six Slides

June 21, 2018

A year ago AMD returned to the server market with its EPYC processor line. The earth didn’t tremble but folks took notice. People remember the Opteron fondly Read more…

By John Russell

MLPerf – Will New Machine Learning Benchmark Help Propel AI Forward?

May 2, 2018

Let the AI benchmarking wars begin. Today, a diverse group from academia and industry – Google, Baidu, Intel, AMD, Harvard, and Stanford among them – releas Read more…

By John Russell

Leading Solution Providers

SC17 Booth Video Tours Playlist

Altair @ SC17

Altair

AMD @ SC17

AMD

ASRock Rack @ SC17

ASRock Rack

CEJN @ SC17

CEJN

DDN Storage @ SC17

DDN Storage

Huawei @ SC17

Huawei

IBM @ SC17

IBM

IBM Power Systems @ SC17

IBM Power Systems

Intel @ SC17

Intel

Lenovo @ SC17

Lenovo

Mellanox Technologies @ SC17

Mellanox Technologies

Microsoft @ SC17

Microsoft

Penguin Computing @ SC17

Penguin Computing

Pure Storage @ SC17

Pure Storage

Supericro @ SC17

Supericro

Tyan @ SC17

Tyan

Univa @ SC17

Univa

Pattern Computer – Startup Claims Breakthrough in ‘Pattern Discovery’ Technology

May 23, 2018

If it weren’t for the heavy-hitter technology team behind start-up Pattern Computer, which emerged from stealth today in a live-streamed event from San Franci Read more…

By John Russell

Sandia to Take Delivery of World’s Largest Arm System

June 18, 2018

While the enterprise remains circumspect on prospects for Arm servers in the datacenter, the leadership HPC community is taking a bolder, brighter view of the x86 server CPU alternative. Amongst current and planned Arm HPC installations – i.e., the innovative Mont-Blanc project, led by Bull/Atos, the 'Isambard’ Cray XC50 going into the University of Bristol, and commitments from both Japan and France among others -- HPE is announcing that it will be supply the United States National Nuclear Security Administration (NNSA) with a 2.3 petaflops peak Arm-based system, named Astra. Read more…

By Tiffany Trader

D-Wave Breaks New Ground in Quantum Simulation

July 16, 2018

Last Friday D-Wave scientists and colleagues published work in Science which they say represents the first fulfillment of Richard Feynman’s 1982 notion that Read more…

By John Russell

Intel Pledges First Commercial Nervana Product ‘Spring Crest’ in 2019

May 24, 2018

At its AI developer conference in San Francisco yesterday, Intel embraced a holistic approach to AI and showed off a broad AI portfolio that includes Xeon processors, Movidius technologies, FPGAs and Intel’s Nervana Neural Network Processors (NNPs), based on the technology it acquired in 2016. Read more…

By Tiffany Trader

Intel Announces Cooper Lake, Advances AI Strategy

August 9, 2018

Intel's chief datacenter exec Navin Shenoy kicked off the company's Data-Centric Innovation Summit Wednesday, the day-long program devoted to Intel's datacenter Read more…

By Tiffany Trader

TACC’s ‘Frontera’ Supercomputer Expands Horizon for Extreme-Scale Science

August 29, 2018

The National Science Foundation and the Texas Advanced Computing Center announced today that a new system, called Frontera, will overtake Stampede 2 as the fast Read more…

By Tiffany Trader

GPUs Power Five of World’s Top Seven Supercomputers

June 25, 2018

The top 10 echelon of the newly minted Top500 list boasts three powerful new systems with one common engine: the Nvidia Volta V100 general-purpose graphics proc Read more…

By Tiffany Trader

The Machine Learning Hype Cycle and HPC

June 14, 2018

Like many other HPC professionals I’m following the hype cycle around machine learning/deep learning with interest. I subscribe to the view that we’re probably approaching the ‘peak of inflated expectation’ but not quite yet starting the descent into the ‘trough of disillusionment. This still raises the probability that... Read more…

By Dairsie Latimer

  • arrow
  • Click Here for More Headlines
  • arrow
Do NOT follow this link or you will be banned from the site!
Share This