Compilers and More: Precision and Accuracy

By Michael Wolfe

May 11, 2007

According to Wikipedia, precision is defined in engineering and science as the degree of agreement among a series of individual measurements or results. For instance, if I measure my height (nonmetrically) five days in a row and come up with 73.8″, 73.5″, 73.75″, 73.7″ and 73.6″, I could state that I’m just over 6 feet tall. The precision of the measurements is about three tenths of an inch, the range of the measurements.

Accuracy is the degree of agreement of a measure value with the actual value. If you know the actual value, you hardly need to measure it, except perhaps to determine the accuracy of the measuring tool. If you don’t know the actual value, you might infer the accuracy of the measurement from the precision of your measurements, if you believe your measuring tool is reasonably accurate. When asked, I usually say I’m 6’2″ tall, which is reasonably accurate, though not exact.

In computing, we use precision in two ways. One is the number of bits in the representation of the mantissa of a floating point number; for instance, single-precision IEEE floating point gives 24 bits of precision (counting the hidden bit for normalized numbers), about 7 decimal digits; double-precision (or full precision, as numerical analysts used to call it) provides 53 bits of precision, about 15 decimal digits.

We also use precision as a measure of how many of these bits are correct. For instance, if I represent a very precise measurement of 1.000100 as a single precision number, then subtract 1.0 from that, the floating point result is 1.000000E-4; since the original measurement was only precise to seven digits, this difference is only precise to three digits, despite being represented with 7 digits. As another simple example, try summing 1/i in single precision where i ranges from 1 to 10,000,000; then sum the numbers in the other order, from 1/10,000,000 to 1/1; here, the answers differ in the second digit. The computations are mathematically identical, but computationally different, because of the limited accuracy of the computer floating point representation. The key is the order of computations can change the floating point answers, due to differences in the order and magnitude of rounding, itself due to the limited size of the representation. Numerical analysts earn a living determining how accurate and precise a computed answer is, and how to formulate the computation to improve accuracy and precision. The rest of us address the problem by going to double precision and hoping for the best.

It’s well known that a compiler can change the order of computations, and yes, this can affect the answers delivered. This dates back at least to the early days of vectorizing compilers for the Texas Instruments ASC, Control Data Cyber 205, and Cray 1. The simplest example was the way a summation is accumulated in vector mode. In our simple example, we showed two orders (forward and backward). These vector computers accumulated some number of intermediate partial sums, then add up the partial sums for a final result. The Cray compiler, for instance, would accumulate a sum in groups of 64 partial sums, the length of the vector register. The Cyber 205 would accumulate eight partial sums, the pipeline depth of the floating point adder. In all cases, the compiler had a flag to preserve the same floating point computation order, but that could be significantly slower.

This is not just historically interesting; many current processors have multimedia or SIMD instruction set extensions, such as the SSE and SSE2 instructions on the Intel and AMD x64 processors. Current compilers use the same code generation scheme to vectorize summations as compilers did 30 years ago for vector machines, though the ‘vector length’ may be only 2 or 4, the size of the multimedia registers.

In addition, a language definition may allow some freedom of evaluation order. Fortran allows a compiler to evaluate any mathematically equivalent expression, provided that parentheses are not violated. C does not even protect parenthesized subexpressions, explicitly allowing reassociation and even redistribution of multiply over addition.

Why this matters

It’s also well known that floating point operations, in spite of gigahertz clocks, functional unit pipelines and all the other architectural magic, are relatively slow. Multiplication is slower than addition, and division or square root is up to ten times slower than that. For those in the high performance world, reducing the multiply count, or replacing multiplication by addition, or, even better, replacing division by multiplication can give a big performance boost. It’s hard to underestimate the importance of benchmark performance in the world of compiler and processor vendors, where bragging rights, pricing, and sales can all depend on a particular benchmark or suite.

So let’s take the case of a particular benchmark, Gromacs, from the SPEC CPU2006 suite. This benchmark has a large number of single precision square root function calls, many of which are in the denominator, such as 1.0/sqrt(rsq11). Several current microprocessors have an instruction to approximate a single-precision inverse square root, such as the PowerPC (AltiVec), the Intel (SSE) and AMD (3D-Now! and SSE). In all cases, the instruction gives a low precision approximation, about half the number of bits. One Newton-Raphson iteration is enough to improve the result to full precision.

Such a technique is well known; the Cray 1 implemented a reciprocal approximate instead of a divide instruction, requiring the compiler to generate the Newton-Raphson iteration to generate a full precision result. This allowed divides to be vector pipelined without undue hardware requirements.

The performance of the square root and divide units are so slow that doing the reciprocal square root approximate instruction, followed by a Newton-Raphson iteration involving four multiplies and a substract, is still quite a bit faster. In some applications (graphics, for example), full precision may be overkill anyway, so perhaps the approximation by itself is sufficient.

So, all is well, right?

The problem is that one iteration of Newton-Raphson is enough to bring the approximation to full precision, except for the last ULP (unit in the last place) or two. This means that using the optimized code in this benchmark generates slightly different results than the standard code that uses a library or full-precision square root and divide instructions.

So, are the answers right or not?

This is tough question, perhaps one that doesn’t make sense. Recall that there’s a certain amount of roundoff error for any computer floating point arithmetic, so the answer is “wrong” whichever way you compute this value. Moreover, the computation is probably based on some initial data that was measured or approximated and so doesn’t have that much precision to start with.

So, are the answers okay or not?

As long as the programmer and the user realize and agree with the limitations of the generated code, yes, they are okay. There are really only two problems. In the history of floating point arithmetic, we’ve had a myriad of floating point formats, from base 16 to two, with or without rounding, with wildly varying dynamic range. In the 1980s, IEEE sponsored an effort to standardize on floating point formats, which all current mainstream processors use. This means that the answers computed on one brand processor, be it AMD, IBM, or Intel, are going to be the same as on any other brand, such as Motorola, MIPS, or SPARC. But here, we’re changing the computation, so the first problem is that answers on different hardware will be close, but may no longer be exactly the same.

The other problem has to do with the programmer and user agreeing with the limitations. Compilers that implement this performance optimization will enable or disable it under programmer control, usually with a command-line option (for those of us still using command lines). The issue is what’s the default? Would you like to specify an additional option to relax the precision of these operations, or specify an additional option to maintain their precision? This is largely a marketing question, though having an option to ‘maintain precision’ makes one wonder what the default behavior is.

As with all SPEC CPU2006 benchmarks, Gromacs checks that the computed answers are correct. However, the check is weak enough that the reciprocal square root approximation is good enough; the Newton-Raphson iteration isn’t even necessary. And yes, some of those SPEC submissions use this “optimization” in their peak numbers. Beware! Dragons lurk here!

Perhaps compilers could take another step and provide an option that would aggressively reorder and reassociate operations, and in general play heck with the floating point rounding properties of the program. If you run your program in standard and reordered mode and the answers are the same, you could have some degree of confidence that the language, the compiler, and the hardware did nothing bad to your computation (though the physics, of course, is up to you). However, if the answers differed wildly, then perhaps you need to bring in that numerical analyst to determine just what makes your program so sensitive.

As clock rates peak, we will explore ever more bizarre mechanisms to improve performance. There’s a lot of buzz about GPGPUs (General Purpose computing on Graphics Processing Units), which are cheap and fast, but which don’t (yet) implement all the IEEE rounding modes. We could quickly degrade into a world much like 20 years ago, where you must consider the hardware floating point representation and implementation before choosing your hardware.

Precision control can also affect performance. Recent numerical library work at Oak Ridge National Labs and the University of Tennessee uses the fact that single precision (32-bit) floating point operations run much faster than double precision on many current processors. The packed SSE instructions on the x64 processors, for instance, can do twice as many 32-bit operations per cycle. This encourages them to redesign their libraries to do the bulk of the work in single precision, then to use iterative refinement in double precision to provide a high precision result with low precision speed.

On the other hand, some scientists are concerned about how quickly roundoff error accumulates when performing peta-operations, perhaps reducing the number of significant digits to zero. Eighteen years ago, David Bailey and others predicted that IEEE double precision floating point would run out of bits as problem sizes increased, and suggested that hardware 128-bit floating point would be needed. Perhaps those SSE registers will soon be holding a single value.

—–

Michael Wolfe has developed compilers for over 30 years in both academia and industry, and is now a senior compiler engineer at The Portland Group, Inc. (www.pgroup.com), a wholly-owned subsidiary of STMicroelectronics, Inc. The opinions stated here are those of the author, and do not represent opinions of The Portland Group, Inc. or STMicroelectronics, Inc.

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!

China’s Expanding Effort to Win in Microchips

July 27, 2017

The global battle for preeminence, or at least national independence, in semiconductor technology and manufacturing continues to heat up with Europe, China, Japan, and the U.S. all vying for sway. A fascinating article ( Read more…

By John Russell

Hyperion: Storage to Lead HPC Growth in 2016-2021

July 27, 2017

Global HPC external storage revenues will grow 7.8% over the 2016-2021 timeframe according to an updated forecast released by Hyperion Research this week. HPC server sales, by comparison, will grow a modest 5.8% to $14.8 Read more…

By John Russell

Exascale FY18 Budget – The Senate Provides Their Input

July 27, 2017

In the federal budgeting world, “regular order” is a meaningful term that is fondly remembered by members of both the Congress and the Executive Branch. Regular order is the established process whereby an Administrat Read more…

By Alex R. Larzelere

HPE Extreme Performance Solutions

HPE Servers Deliver High Performance Remote Visualization

Whether generating seismic simulations, locating new productive oil reservoirs, or constructing complex models of the earth’s subsurface, energy, oil, and gas (EO&G) is a highly data-driven industry. Read more…

India Plots Three-Phase Indigenous Supercomputing Strategy

July 26, 2017

Additional details on India's plans to stand up an indigenous supercomputer came to light earlier this week. As reported in the Indian press, the Rs 4,500-crore (~$675 million) supercomputing project, approved by the Ind Read more…

By Tiffany Trader

Exascale FY18 Budget – The Senate Provides Their Input

July 27, 2017

In the federal budgeting world, “regular order” is a meaningful term that is fondly remembered by members of both the Congress and the Executive Branch. Reg Read more…

By Alex R. Larzelere

India Plots Three-Phase Indigenous Supercomputing Strategy

July 26, 2017

Additional details on India's plans to stand up an indigenous supercomputer came to light earlier this week. As reported in the Indian press, the Rs 4,500-crore Read more…

By Tiffany Trader

Tuning InfiniBand Interconnects Using Congestion Control

July 26, 2017

InfiniBand is among the most common and well-known cluster interconnect technologies. However, the complexities of an InfiniBand (IB) network can frustrate the Read more…

By Adam Dorsey

NSF Project Sets Up First Machine Learning Cyberinfrastructure – CHASE-CI

July 25, 2017

Earlier this month, the National Science Foundation issued a $1 million grant to Larry Smarr, director of Calit2, and a group of his colleagues to create a comm Read more…

By John Russell

Graphcore Readies Launch of 16nm Colossus-IPU Chip

July 20, 2017

A second $30 million funding round for U.K. AI chip developer Graphcore sets up the company to go to market with its “intelligent processing unit” (IPU) in Read more…

By Tiffany Trader

Fujitsu Continues HPC, AI Push

July 19, 2017

Summer is well under way, but the so-called summertime slowdown, linked with hot temperatures and longer vacations, does not seem to have impacted Fujitsu's out Read more…

By Tiffany Trader

Researchers Use DNA to Store and Retrieve Digital Movie

July 18, 2017

From abacus to pencil and paper to semiconductor chips, the technology of computing has always been an ever-changing target. The human brain is probably the com Read more…

By John Russell

The Exascale FY18 Budget – The Next Step

July 17, 2017

On July 12, 2017, the U.S. federal budget for its Exascale Computing Initiative (ECI) took its next step forward. On that day, the full Appropriations Committee Read more…

By Alex R. Larzelere

Google Pulls Back the Covers on Its First Machine Learning Chip

April 6, 2017

This week Google released a report detailing the design and performance characteristics of the Tensor Processing Unit (TPU), its custom ASIC for the inference Read more…

By Tiffany Trader

Nvidia Responds to Google TPU Benchmarking

April 10, 2017

Nvidia highlights strengths of its newest GPU silicon in response to Google's report on the performance and energy advantages of its custom tensor processor. Read more…

By Tiffany Trader

Quantum Bits: D-Wave and VW; Google Quantum Lab; IBM Expands Access

March 21, 2017

For a technology that’s usually characterized as far off and in a distant galaxy, quantum computing has been steadily picking up steam. Just how close real-wo Read more…

By John Russell

HPC Compiler Company PathScale Seeks Life Raft

March 23, 2017

HPCwire has learned that HPC compiler company PathScale has fallen on difficult times and is asking the community for help or actively seeking a buyer for its a Read more…

By Tiffany Trader

Trump Budget Targets NIH, DOE, and EPA; No Mention of NSF

March 16, 2017

President Trump’s proposed U.S. fiscal 2018 budget issued today sharply cuts science spending while bolstering military spending as he promised during the cam Read more…

By John Russell

CPU-based Visualization Positions for Exascale Supercomputing

March 16, 2017

In this contributed perspective piece, Intel’s Jim Jeffers makes the case that CPU-based visualization is now widely adopted and as such is no longer a contrarian view, but is rather an exascale requirement. Read more…

By Jim Jeffers, Principal Engineer and Engineering Leader, Intel

Nvidia’s Mammoth Volta GPU Aims High for AI, HPC

May 10, 2017

At Nvidia's GPU Technology Conference (GTC17) in San Jose, Calif., this morning, CEO Jensen Huang announced the company's much-anticipated Volta architecture a Read more…

By Tiffany Trader

How ‘Knights Mill’ Gets Its Deep Learning Flops

June 22, 2017

Intel, the subject of much speculation regarding the delayed, rewritten or potentially canceled “Aurora” contract (the Argonne Lab part of the CORAL “ Read more…

By Tiffany Trader

Leading Solution Providers

Facebook Open Sources Caffe2; Nvidia, Intel Rush to Optimize

April 18, 2017

From its F8 developer conference in San Jose, Calif., today, Facebook announced Caffe2, a new open-source, cross-platform framework for deep learning. Caffe2 is the successor to Caffe, the deep learning framework developed by Berkeley AI Research and community contributors. Read more…

By Tiffany Trader

Reinders: “AVX-512 May Be a Hidden Gem” in Intel Xeon Scalable Processors

June 29, 2017

Imagine if we could use vector processing on something other than just floating point problems.  Today, GPUs and CPUs work tirelessly to accelerate algorithms Read more…

By James Reinders

Russian Researchers Claim First Quantum-Safe Blockchain

May 25, 2017

The Russian Quantum Center today announced it has overcome the threat of quantum cryptography by creating the first quantum-safe blockchain, securing cryptocurrencies like Bitcoin, along with classified government communications and other sensitive digital transfers. Read more…

By Doug Black

MIT Mathematician Spins Up 220,000-Core Google Compute Cluster

April 21, 2017

On Thursday, Google announced that MIT math professor and computational number theorist Andrew V. Sutherland had set a record for the largest Google Compute Engine (GCE) job. Sutherland ran the massive mathematics workload on 220,000 GCE cores using preemptible virtual machine instances. Read more…

By Tiffany Trader

Google Debuts TPU v2 and will Add to Google Cloud

May 25, 2017

Not long after stirring attention in the deep learning/AI community by revealing the details of its Tensor Processing Unit (TPU), Google last week announced the Read more…

By John Russell

Groq This: New AI Chips to Give GPUs a Run for Deep Learning Money

April 24, 2017

CPUs and GPUs, move over. Thanks to recent revelations surrounding Google’s new Tensor Processing Unit (TPU), the computing world appears to be on the cusp of Read more…

By Alex Woodie

Six Exascale PathForward Vendors Selected; DoE Providing $258M

June 15, 2017

The much-anticipated PathForward awards for hardware R&D in support of the Exascale Computing Project were announced today with six vendors selected – AMD Read more…

By John Russell

Top500 Results: Latest List Trends and What’s in Store

June 19, 2017

Greetings from Frankfurt and the 2017 International Supercomputing Conference where the latest Top500 list has just been revealed. Although there were no major Read more…

By Tiffany Trader

  • arrow
  • Click Here for More Headlines
  • arrow
Share This