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!

SC Bids Farewell to Denver, Heads to Dallas for 30th

November 17, 2017

After a jam-packed four-day expo and intensive six-day technical program, SC17 has wrapped up another successful event that brought together nearly 13,000 visitors to the Colorado Convention Center in Denver for the larg Read more…

By Tiffany Trader

SC17 Keynote – HPC Powers SKA Efforts to Peer Deep into the Cosmos

November 17, 2017

This week’s SC17 keynote – Life, the Universe and Computing: The Story of the SKA Telescope – was a powerful pitch for the potential of Big Science projects that also showcased the foundational role of high performance computing in modern science. It was also visually stunning. Read more…

By John Russell

How Cities Use HPC at the Edge to Get Smarter

November 17, 2017

Cities are sensoring up, collecting vast troves of data that they’re running through predictive models and using the insights to solve problems that, in some cases, city managers didn’t even know existed. Speaking Read more…

By Doug Black

HPE Extreme Performance Solutions

Harness Scalable Petabyte Storage with HPE Apollo 4510 and HPE StoreEver

As a growing number of connected devices challenges IT departments to rapidly collect, manage, and store troves of data, organizations must adopt a new generation of IT to help them operate quickly and intelligently. Read more…

SC17 Student Cluster Competition Configurations: Fewer Nodes, Way More Accelerators

November 16, 2017

The final configurations for each of the SC17 “Donnybrook in Denver” Student Cluster Competition have been released. Fortunately, each team received their equipment shipments on time and undamaged, so the teams are r Read more…

By Dan Olds

SC Bids Farewell to Denver, Heads to Dallas for 30th

November 17, 2017

After a jam-packed four-day expo and intensive six-day technical program, SC17 has wrapped up another successful event that brought together nearly 13,000 visit Read more…

By Tiffany Trader

SC17 Keynote – HPC Powers SKA Efforts to Peer Deep into the Cosmos

November 17, 2017

This week’s SC17 keynote – Life, the Universe and Computing: The Story of the SKA Telescope – was a powerful pitch for the potential of Big Science projects that also showcased the foundational role of high performance computing in modern science. It was also visually stunning. Read more…

By John Russell

How Cities Use HPC at the Edge to Get Smarter

November 17, 2017

Cities are sensoring up, collecting vast troves of data that they’re running through predictive models and using the insights to solve problems that, in some Read more…

By Doug Black

Student Cluster LINPACK Record Shattered! More LINs Packed Than Ever before!

November 16, 2017

Nanyang Technological University, the pride of Singapore, utterly destroyed the Student Cluster Competition LINPACK record by posting a score of 51.77 TFlop/s a Read more…

By Dan Olds

Hyperion Market Update: ‘Decent’ Growth Led by HPE; AI Transparency a Risk Issue

November 15, 2017

The HPC market update from Hyperion Research (formerly IDC) at the annual SC conference is a business and social “must,” and this year’s presentation at S Read more…

By Doug Black

Nvidia Focuses Its Cloud Containers on HPC Applications

November 14, 2017

Having migrated its top-of-the-line datacenter GPU to the largest cloud vendors, Nvidia is touting its Volta architecture for a range of scientific computing ta Read more…

By George Leopold

HPE Launches ARM-based Apollo System for HPC, AI

November 14, 2017

HPE doubled down on its memory-driven computing vision while expanding its processor portfolio with the announcement yesterday of the company’s first ARM-base Read more…

By Doug Black

OpenACC Shines in Global Climate/Weather Codes

November 14, 2017

OpenACC, the directive-based parallel programming model used mostly for porting codes to GPUs for use on heterogeneous systems, came to SC17 touting impressive Read more…

By John Russell

US Coalesces Plans for First Exascale Supercomputer: Aurora in 2021

September 27, 2017

At the Advanced Scientific Computing Advisory Committee (ASCAC) meeting, in Arlington, Va., yesterday (Sept. 26), it was revealed that the "Aurora" supercompute Read more…

By Tiffany Trader

NERSC Scales Scientific Deep Learning to 15 Petaflops

August 28, 2017

A collaborative effort between Intel, NERSC and Stanford has delivered the first 15-petaflops deep learning software running on HPC platforms and is, according Read more…

By Rob Farber

Oracle Layoffs Reportedly Hit SPARC and Solaris Hard

September 7, 2017

Oracle’s latest layoffs have many wondering if this is the end of the line for the SPARC processor and Solaris OS development. As reported by multiple sources Read more…

By John Russell

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

AMD Showcases Growing Portfolio of EPYC and Radeon-based Systems at SC17

November 13, 2017

AMD’s charge back into HPC and the datacenter is on full display at SC17. Having launched the EPYC processor line in June along with its MI25 GPU the focus he Read more…

By John Russell

Google Releases Deeplearn.js to Further Democratize Machine Learning

August 17, 2017

Spreading the use of machine learning tools is one of the goals of Google’s PAIR (People + AI Research) initiative, which was introduced in early July. Last w Read more…

By John Russell

GlobalFoundries Puts Wind in AMD’s Sails with 12nm FinFET

September 24, 2017

From its annual tech conference last week (Sept. 20), where GlobalFoundries welcomed more than 600 semiconductor professionals (reaching the Santa Clara venue Read more…

By Tiffany Trader

Amazon Debuts New AMD-based GPU Instances for Graphics Acceleration

September 12, 2017

Last week Amazon Web Services (AWS) streaming service, AppStream 2.0, introduced a new GPU instance called Graphics Design intended to accelerate graphics. The Read more…

By John Russell

Leading Solution Providers

EU Funds 20 Million Euro ARM+FPGA Exascale Project

September 7, 2017

At the Barcelona Supercomputer Centre on Wednesday (Sept. 6), 16 partners gathered to launch the EuroEXA project, which invests €20 million over three-and-a-half years into exascale-focused research and development. Led by the Horizon 2020 program, EuroEXA picks up the banner of a triad of partner projects — ExaNeSt, EcoScale and ExaNoDe — building on their work... Read more…

By Tiffany Trader

Delays, Smoke, Records & Markets – A Candid Conversation with Cray CEO Peter Ungaro

October 5, 2017

Earlier this month, Tom Tabor, publisher of HPCwire and I had a very personal conversation with Cray CEO Peter Ungaro. Cray has been on something of a Cinderell Read more…

By Tiffany Trader & Tom Tabor

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

Cray Moves to Acquire the Seagate ClusterStor Line

July 28, 2017

This week Cray announced that it is picking up Seagate's ClusterStor HPC storage array business for an undisclosed sum. "In short we're effectively transitioning the bulk of the ClusterStor product line to Cray," said CEO Peter Ungaro. Read more…

By Tiffany Trader

Intel Launches Software Tools to Ease FPGA Programming

September 5, 2017

Field Programmable Gate Arrays (FPGAs) have a reputation for being difficult to program, requiring expertise in specialty languages, like Verilog or VHDL. Easin Read more…

By Tiffany Trader

HPC Chips – A Veritable Smorgasbord?

October 10, 2017

For the first time since AMD's ill-fated launch of Bulldozer the answer to the question, 'Which CPU will be in my next HPC system?' doesn't have to be 'Whichever variety of Intel Xeon E5 they are selling when we procure'. Read more…

By Dairsie Latimer

IBM Advances Web-based Quantum Programming

September 5, 2017

IBM Research is pairing its Jupyter-based Data Science Experience notebook environment with its cloud-based quantum computer, IBM Q, in hopes of encouraging a new class of entrepreneurial user to solve intractable problems that even exceed the capabilities of the best AI systems. Read more…

By Alex Woodie

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

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