SIMD – HPCwirehttps://www.hpcwire.com
Since 1987 - Covering the Fastest Computers in the World and the People Who Run ThemTue, 26 Sep 2017 18:39:43 +0000en-UShourly1https://wordpress.org/?v=4.8.260365857HPC Programming in the Age of Multicore: One Man’s Viewhttps://www.hpcwire.com/2013/01/14/hpc_programming_in_the_age_of_multicore_one_man_s_view/?utm_source=rss&utm_medium=rss&utm_campaign=hpc_programming_in_the_age_of_multicore_one_man_s_view
https://www.hpcwire.com/2013/01/14/hpc_programming_in_the_age_of_multicore_one_man_s_view/#respondMon, 14 Jan 2013 08:00:00 +0000http://www.hpcwire.com/?p=4223<img style="float: left;" src="http://media2.hpcwire.com/hpcwire/Gerhard_Wellein_small.jpg" alt="" width="95" height="85" />At this June's International Supercomputing Conference (ISC'13) in Leipzig, Germany, Gerhard Wellein will be delivering a keynote entitled, Fooling the Masses with Performance Results: Old Classics & Some New Ideas. HPCwire caught up with Wellein and asked him to preview some of the themes of his upcoming talk and expound on his philosophy of programming for performance in the multicore era.

Application developers looking for a foundational treatment of HPC programming need look no further than the 2010 text, Introduction to High Performance Computing for Scientists and Engineers, which describes the art of extracting maximum performance from modern processors and HPC platforms. Gerhard Wellein, who co-authored the book with colleague Georg Hager, has made a career of teaching HPC techniques to aspiring students in science and engineering programs.

Currently a professor at the Department for Computer Science at the University of Erlangen-Nuremberg, Wellein also heads the HPC group at the Erlangen Regional Computing Center (RRZE). Like many in HPC today, he came from a science background, in this case physics, and specifically solid state physics. Wellein holds a PhD in the subject from Germany’s University of Bayreuth, and his interest in parallel and HPC programming stem from the intense computation demands of his original field of study.

HPCwire caught up with Wellein and asked him to preview some of the themes of his upcoming talk and expound on strategies for performance programming in the multicore era.

HPCwire: Multicore processors have been with us for more than a decade. In general, do you think programmers and programming has caught up to this computing paradigm?

Gerhard Wellein: Many software developers mainly focus on extendibility, flexibility and maintainability for their frameworks. Performance or better time to solution has not been an issue for them for two decades. Teaching in computer science still often ignores performance issues.

The same holds for parallelization – here the developers often hope that some other software layer – compiler or libraries – will do the job. However, people should become aware that improving time to solution, through hardware efficient code structures and parallelization, is not for free and often orthogonal to widely accepted concepts in modern programming languages and software engineering paradigms.

In a very provocative statement I would say that “abstraction is the natural enemy of performance.” To mitigate this problem, software developers need to understand the interaction of the different software layers, including compilers, with the basic hardware structures at least at a coarse level, and consider this relationship when designing and implementing the performance-critical path of the software.

HPCwire: In general, why is it so hard to extract peak performance from multicore processors?

Wellein: Modern multicore processors draw their performance from thread-level parallelism and data parallelism, that is, multiple cores and wide SIMD units per core. The programmer has to address both hardware features at the same time and needs optimize for them; otherwise he loses a substantial fraction of peak performance. If the compiler, for some reason, refuses to vectorize your single precision arithmetic code, you immediately lose almost 90 percent of the available peak performance on the latest Intel processors!

Then you need to do the job on your own. But who uses SIMD intrinsics or even programs assembly language? The same holds for multicore parallelization. Here load imbalances or dependencies can severely limit multicore efficiency from the start.

Moreover multicores have plenty of shared resources such as caches and memory interfaces which carry the risk of contention. One also should be aware that the maximum attainable performance always depends on the problem to be solved. Sparse matrix solvers working on irregular problems typically can only achieve a single digit fraction of peak performance, due to main memory bandwidth limitations. The architecture of modern multicores strongly favors problems which run from cache and have high spatial and temporal locality in their data access, which excludes large application areas from getting close to peak performance. HPCwire: What kinds of tools and techniques for multicore programming are available that are not being commonly employed now?

Wellein: There is no lack of advanced tools. Often I have the impression that there are too many tools, frameworks and parallel programming models out there and many software developers get lost.

What is missing is a comprehensive understanding of the attainable performance for a give code or algorithm on a given hardware platform. Performance modeling is a structured process to analyze the interaction of hardware and software in order to predict the best performance levels both in serial and parallel applications. Comparing actual and predicted performance identifies inefficient code parts and opportunities for code optimization. Thus I feel that for time-critical applications, performance modeling should be integral part of the software development cycle.

HPCwire: If you had to pick one or two attributes of modern processors that hinders the ability of HPC developers to extract performance, what would it be?

Wellein: Performance improvements in multicores are driven mainly by two factors – SIMD and multicore parallelism – which need to be explicitly addressed by the programmer. The compiler alone will not do the job! In the good old days of the clock speed race, performance was boosted by the increasing processor frequency for free.

HPCwire: Is programming for performance different that programming for energy efficiency?

Wellein: No, this is just another side of the same medal. Programming for performance aims to reduce overall runtime. It may increase the power consumption mainly of the processor chip. But what counts at the end of the day is energy to solution, which is the product of both. All optimizations which substantially improve time to solution also reduce overall energy consumption.

What is even more interesting is that with a well optimized serial code you need fewer cores to saturate performance on the multicore chip. This now offers the interesting option to substantially reduce the clock speed of multicores or switch off cores completely! Some people may still complain that this makes your code less scalable on multicores. That is true but it improves energy efficiency and time to solution.

HPCwire: What do you think of the latest vector accelerators: GPUs and Intel’s latest Xeon Phi line, or even the general-purpose DSPs from Texas Instruments? Is this a reasonable approach for vector computing or do you see this as an intermediate step to something else?

Wellein: Those approaches trade in hardware complexity for additional performance, thus shifting additional work load to the programmer. Application performance on those architectures is typically much more susceptible to programmer’s capability to write highly efficient code. At the “core” level they draw their performance from the same concepts as vector computers did, namely fine-grained data parallelism with a wide SIMD approach. The product of those two factors on an Intel Xeon Phi processor makes performance approximately 15 times higher than on a state-of-the art Xeon EP processor, making the accelerator even more sensitive to inefficient codes.

From classical vector computers they differ in the sense that accelerators are mainly optimized for FLOPS and not for FLOPS-to-byte ratios. This also becomes evident if you look at the hierarchical memory subsystems which do not provide the ease of use of the simple flat designs of vector computers.

Increasing fine-grained data parallelism in hardware may further boost the FLOPS of future accelerators, but will further decrease the FLOPS-to-byte ratios. Also non-SIMD parts in the codes may soon become severe bottlenecks – with greetings from Gene Amdahl! HPCwire: Does the mass market for processors – generic servers, PCs, and now especially mobile devices – serve the needs of HPC? Do you think there is a reasonable cost/benefit for developing more specialized processors for this domain?

Wellein: The rapid development cycles and cost reductions of the mass markets have substantially fostered progress in computational science and engineering in the past decade. These achievements opened HPC capacities for the “masses” in science and engineering.

I do not feel that most of those users are today willing to pay a high price premium to develop specialized hardware solutions, which means for them to trade in capability for capacity. What is happening to the last vendor of specialized processors for supercomputing – NEC with its vector computing processors – is a good example. In recent years NEC lost many of their customers in the weather and climate community, one of the few communities that asked for specialized HPC solutions for a long time. The Lattice QCD community is still building specialized solutions, such as the QPACE project, but also gave up designing its own processors.

The requirements to an “optimal processor” differ substantially among the application communities and making specialized designs for each of them is economically unattractive for most of the users. They take what they get from the mass market vendors. As long as those deliver processors which provide a good compromise between “time to solution,” aka capability, and “throughput,” aka capacity, for most users, there is not enough pressure for large-scale investments in specialized HPC processors.

I do not feel comfortable with that trend because there is tendency to blame the application that it cannot make efficient use of those processors and one should adapt the solver or even the physical model to the processor! A provocative summary of this trend: “Seymour Cray built machines to solve problems. Today we look for problems which we can solve on the machines available!”

]]>https://www.hpcwire.com/2013/01/14/hpc_programming_in_the_age_of_multicore_one_man_s_view/feed/04223Novel Chip Technology to Power GRAPE-8 Supercomputerhttps://www.hpcwire.com/2012/05/10/novel_chip_technology_to_power_grape-8_supercomputer/?utm_source=rss&utm_medium=rss&utm_campaign=novel_chip_technology_to_power_grape-8_supercomputer
https://www.hpcwire.com/2012/05/10/novel_chip_technology_to_power_grape-8_supercomputer/#respondThu, 10 May 2012 07:00:00 +0000http://www.hpcwire.com/?p=4473<img style="float: left;" src="http://media2.hpcwire.com/hpcwire/eASIC_logo_small.jpg" alt="" width="108" height="34" />With the fastest supercomputers on the planet sporting multi-megawatt appetites, green HPC has become all the rage. The IBM Blue Gene/Q machine is currently number one in energy-efficient flops, but a new FPGA-like technology brought to market by semiconductor startup eASIC is providing an even greener computing solution. And one HPC project in Japan, known as GRAPE, is using the chips to power its newest supercomputer.

With the fastest supercomputers on the planet sporting multi-megawatt appetites, green HPC has become all the rage. The IBM Blue Gene/Q machine is currently number one in energy-efficient flops, but a new FPGA-like technology brought to market by semiconductor startup eASIC is providing an even greener computing solution. And one HPC project in Japan, known as GRAPE, is using the chips to power its newest supercomputer.

GRAPE, which stands for Gravity Pipe, is a Japanese computing project that is focused on astrophysical simulation. (More specifically, the application uses Newtonian physics to compute the interaction of particles in N-body systems). The project, which began in 1989, has gone through eight generations of hardware, all of which were built as special-purpose supercomputer systems.

Each of the GRAPE machines was powered by a custom-built chip, specifically designed to optimize the astrophysical calculations that form the basis of the simulation work. The special-purpose processors were hooked up as external accelerators, using more conventional CPU-based host systems, in the form or workstations or servers, to drive the application.

The first-generation machine, GRAPE-1, managed just 240 single precision megaflops in 1989. The following year, the team build a double precision processor, which culminated in the 40-megaflop GRAPE-2. In 1998, they fielded GRAPE-4, their first teraflop system. The most recently system, GRAPE-DR, was designed to be a petascale machine, although its TOP500 entry showed up in 2009 as an 84.5 teraflop cluster.

Even though the GRAPE team was able to squeeze a lot more performance out of specially built hardware than they would have using general-purpose HPC machinery, it’s an expensive proposition. Each GRAPE iteration was based on a different ASIC design, necessitating the costly and time-consuming process of chip design, verification, and production. And as transistor geometries shrunk, development costs soared.

As the GRAPE team at Hitotsubashi University and the Tokyo Institute of Technology began planning the next generation, they decided that chip R&D could take up no more than a quarter of system’s cost. But given the escalating expense of processor development, they would overshoot that by a wide margin. In 2010, they estimated it would take on the order of $10 million to develop a new custom ASIC on 45nm technology. So when it came time for GRAPE-8, the engineers were looking for alternatives.

The natural candidates were GPUs and FPGAs, which offer a lot of computational horsepower in an energy-efficient package. Each had its advantages: FPGAs in customization capability, GPUs in raw computing power. Ultimately though, they opted for a technology developed by eASIC, a fabless semiconductor company that offered a special kind of purpose-built ASIC, based on an FPGA workflow.

The technology had little grounding in high performance computing, being used mostly in embedded platforms, like wireless infrastructure and enterprise storage hardware. But the GRAPE designers were impressed by the efficiency of the technology. With an eASIC chip, they could get the same computational power as an FPGA for a tenth of the size and at about a third of the cost. And although the latest GPUs were slightly more powerful flop-wise than what eASIC could deliver, power consumption was an order of magnitude higher.

In a nutshell, the company offers something between an FPGA and a conventional ASIC. According to Niall Battson, eASIC’s Senior Product Manager, it looks like a field-programmable gate array, but “all the programming circuitry has been taken out.” That saves on both chip real estate and power since that circuitry doesn’t end up on the die.

In essence, the company is able to take an FPGA design (in RTL or whatever) and produce an ASIC from it. But not a conventional one. Battson says their real secret sauce is that the logic is laid down in a single silicon layer, rather than the four or five used for conventional ASICs. That simplification greatly speeds up chip validation and manufacturing, so much so that they can turn around a production chip in 4 to 6 months, depending upon the complexity of the design.

While the logic density and power efficiency are less than that of a standard ASIC, the up-front costs are considerably lower. For customers whose volumes eventually warrant a “true” ASIC (like for disk drive controllers), eASIC provides a service that takes the customer’s design through that final step of hardening.

For the astrophysics simulation supercomputer, no such step was necessary. The 45nm chip eASIC built and delivered for the new GRAPE-8 system achieves close to 500 gigaflops (250 MHz) with a power draw of just 10 watts. The GRAPE-8 accelerator board houses two of these custom chips, plus a standard processor, delivering 960 gigaflops in 46 watts. When hooked up to a PC host, another 200 watts is added. Even in this makeshift configuration, the system achieves 6.5 gigaflops per watt, about three times better that the 2.1 gigaflops per watt held by IBM’s Blue Gene/Q, the current Green500 champ.

Of course, the Blue Gene/Q is a general-purpose supercomputer, so the comparison is bit of apples-to-oranges. But the generality of computer designs exists on a continuum, not as a binary taxonomy. In general, better performance and power efficiency can be achieved as more specialization is incorporated into the hardware. The downside is that such single-application machines are notoriously expensive, which explains why there are so few of them. Besides GRAPE, only the Anton supercomputer (for molecular dynamics simulations) is still using application-specific ASICs.

The GRAPE designers are actually interested in building a more ambidextrous machine to handle a greater variety of science applications. In fact, the GRAPE-DR machine was a bit of a departure from its predecessors and was intended for applications outside of astrophysics simulations, including genome analysis, protein modeling and molecular dynamics.

According to Battson, a more general-purpose SIMD chip is certainly possible under an eASIC scheme, and they’re considering how they might be able to tweak their technology to make that happen. The company’s next generation 28nm product is slated to deliver twice the performance, while halving power consumption, so there is some headroom for added capabilities. The main problem he says is that a general-purpose SIMD ASIC would probably need to run twice as fast as the GRAPE-8 chip to deliver reasonable performance, and that drives up power consumption.

Of course, with the prospect of energy-sucking exascale machines on the horizon, application-specific supercomputing could make a comeback, especially if spinning out purpose-built accelerators was made fast and affordable. In that case, eASIC and its technology might find itself with a lot of eager suitors.

The Chinese-made Godson CPU is apparently getting an upgrade next year. Professor Wei-wu Hu, at Beijing’s Institute of Computing Technology (ICT) presented a paper at the Hot Chips conference this week detailing the new 65nm processors that are scheduled to be delivered in 2011. The Godson is a MIPS-based processor line that the Chinese have developed so as not to be wholly dependent upon foreign vendors for their microprocessor needs.

According to an article in EE Times, the upcoming high-end chip, the Godson 3B, will be a 64-bit server chip with extended vector processing. The 8-core CPU reportedly delivers a whopping 128 gigaflops, but consumes just 40W of power. The vector processing consists of a 256-bit SIMD unit, which include eight 64-bit multiply-accumulate units. All of this floppery appears to be a good fit for HPC, and indeed, some of the chips are destined for supercomputing duty. From the EE times report:

Hu showed several board-level examples of designs that will use the 3B in servers or as nodes in massively parallel supercomputing clusters. Earlier this year Shenzhen-based computer maker Dawning Information Industry Co. Ltd. created a petaflops system based on Intel and Nvidia processors and said its next generation will use the 16-core Godson 3C.

Apparently the Godson 3C version will be manufactured on the 28nm node and is due out in 2012, although there is some question about which fab partner will have the manufacturing technology ready in time. STMicroelectronics is being used for the 65nm Godson 3B, which taped out in May.

Whenever I hear claims of GP-GPU speed up, I often ask “X times better than what?” And, here is where the devil lives. To be a meaningful comparison, the CPU type, speed, memory architecture, compiler, how many cores, precision level, etc. need to be specified. I found many of the performance claims missing much of this key data, which in my world means the speed-up numbers are worthless.

While computational biologists scramble to develop tools to support the analysis of protein sequence, structure, and interaction data, the hardware side of the equation has been sadly neglected. Sequencers frequently ship with small clusters, which are useful only for the most basic processing tasks. The standard processing system in use today is a cluster of Linux servers, but this has led to a bottleneck of a different type.

]]>https://www.hpcwire.com/2010/01/20/accelerated_methods_for_bioinformatics_analysis/feed/05488Is Larrabee For the Rest of Us?https://www.hpcwire.com/2009/11/12/is_larrabee_for_the_rest_of_us/?utm_source=rss&utm_medium=rss&utm_campaign=is_larrabee_for_the_rest_of_us
https://www.hpcwire.com/2009/11/12/is_larrabee_for_the_rest_of_us/#respondThu, 12 Nov 2009 08:00:00 +0000http://www.hpcwire.com/?p=5600One man's attempt to to do regular-expression matching with the Larrabee instruction set.

Larrabee, the new multicore processor that Intel will release in the next months, is going to catch most programmers unprepared. For once, it is difficult to estimate its potential on the basis of the very few details available. And programmers of non-numerical developers, traditionally secondary audience for GPGPU architects, are going to face an even steeper programming challenge.

NVIDIA’s next-generation GPU design, the G300, may turn out to be the biggest architectural leap the graphics chip maker has ever attempted. If the early rumors are true, NVIDIA has decided move the architecture a step closer to the CPU and make GPU computing even more compelling for HPC.

Publicly, the company has been tight-lipped on what the upcoming architecture will look like, but that doesn’t prevent GPU-obsessed journalists from speculating. Some of this speculation may be based on wishful thinking, but it looks like there may be a few loose-lipped NVIDIANs out there giving us a reasonably accurate peek at the silicon. It’s also likely that sources at Taiwan Semiconductor Manufacturing Company (TSMC), NVIDIA’s GPU manufacturing partner, are also feeding the rumor mill.

By the way, the G300 is often referred to as the GT300, but the latter refers only to the high-end Tesla version of the architecture, the one the supercomputing crowd would be most interested in. (Hat tip to Rick Hodgin at geek.com for clearing that up.) For our purposes, I’ll just refer to it as the GT300 since HPC users are going to be mostly interested in the top-of-the-line parts anyway.

What follows is speculation heaped on top of speculation, so be warned that none of this may be true. But it makes for fun reading.

Back in April, Theo Valich in Bright Side of News reported that the new GT300 is going to have a lot more power and flexibility than the current crop of GPUs. Writes Valich:

GT300 isn’t the architecture that was envisioned by nVidia’s Chief Architect, former Stanford professor Bill Dally, but this architecture will give you a pretty good idea why Bill told Intel to take a hike when the larger chip giant from Santa Clara offered him a job on the Larrabee project.

According to Valich’s sources, the GT300 will offer up to 512 cores, up from 240 cores in NVIDIA’s current high-end GPU. Since the new chips will be on the 40nm process node, NVIDIA could also crank up the clock. The current Tesla GPUs are running at 1.3-1.4 GHz and deliver about 1 teraflop, single precision, and less than 100 gigaflops, double precision. Valich speculates that a 2 GHz clock could up that to 3 teraflops of single precision performance, and, because of other architectural changes, double precision performance would get an even larger boost.

In a later post Valich writes that the upcoming GPU will sport a 512-bit interface connected to GDDR5 memory. If true he says, “we are looking at memory bandwidth of 256GB/s per single GPU.”

More importantly though, NVIDIA is said to be moving from the traditional SIMD (single instruction, multiple data) GPU computing model to MIMD (multiple instruction, multiple data) or at least MIMD-like. As the name suggests, MIMD means you can run different instruction streams on different processing units in parallel. It offers a much more flexible way of doing all sorts of vector computing, and is a standard way to do technical programming on SMP machines and clusters. Presumably CUDA will incorporate MIMD extensions to support the new hardware. MIMD also happens to be architecture supported by Intel’s upcoming Larrabee chip.

In fact, both the GT300 and Larrabee may end up dropping into the market at the same time — sometime in the first half of 2010. But, as I’ve reported before, Intel has said it is not targeting the HPC market with Larrabee, at least not for next year. NVIDIA, on the other hand, will almost certainly be pushing GT300 silicon into its HPC Tesla products as soon as possible.

There was some speculation that the GT300 would hit the streets this year, but reports of trouble with TSMC’s 40nm manufacturing technology may have slowed NVIDIA’s plans. Also keep in mind that the new architecture has to drag along a growing list of programming standards — CUDA, DirectX 11, OpenGL 3.1 and OpenCL — so getting the new chips to satisfy everyone is no small feat.

If the speculation about the GT300 is basically true, NVIDIA will significantly expand its commitment to the GPU computing market. The Inquirer’s NVIDIA curmudgeon, Charlie Demerjian, thinks too much so. He writes:

Rather than go lean and mean for GT300, possibly with a multi-die strategy like ATI, Nvidia is going for bigger and less areally efficient. They are giving up GPU performance to chase a market that doesn’t exist, but was a nice fantasy three years ago.

Demerjian’s rant on the GT300 is slanted toward his focus on traditional graphics apps and his obvious antipathy toward NVIDIA, but the point he makes about NVIDIA’s devotion to GPU computing is valid enough.

Let’s face it, if Intel fails to connect with Larrabee, the company will just write it off and keep selling its gazillion other flavors of x86. AMD has a more conservative GPU computing strategy, so it has less to lose if the market fizzles. NVIDIA is the one that has really stuck its neck out. The GT300 just sticks it out a little further.